- 3,733,272 Users
- 2,246,740 Discussions
- 7,856,645 Comments
- 380.9K All Categories
- 2.1K Data
- 203 Big Data Appliance
- 1.9K Data Science
- 446.1K Databases
- 220.4K General Database Discussions
- 22 Multilingual Engine
- 506 MySQL Community Space
- 459 NoSQL Database
- 7.7K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 437 SQLcl
- 3.9K SQL Developer Data Modeler
- 185.4K SQL & PL/SQL
- 20.7K SQL Developer
- 291.2K Development
- 6 Developer Projects
- 116 Programming Languages
- 288K Development Tools
- 96 DevOps
- 3K QA/Testing
- 645.2K Java
- 16 Java Learning Subscription
- 36.9K Database Connectivity
- 148 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.7K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 12 Java Essentials
- 138 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 195 Java User Groups
- 177 LiveLabs
- 33 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 165 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 225 Portuguese
19c Where is OCI_THREAD SET? Seeing same issue as https://community.oracle.com/thread/4266189
We encountered the same issue as https://community.oracle.com/thread/4266189 after migrating to Oracle 19C. We did the following work around and are not seeing the two threads now. Where is OCI_THREADED set in 19c. This never occurred until after the 19c upgrade.
So if you can tell us where OCI_THREADED is set in 19c, maybe down in the client install somewhere? We can not find explicit reference to OCI_DEFAULT or OCI_THREAD
Description of the problem we were seeing listed below which is similar to the 4266189 thread above. Found work arounds listed in the bug fixes.
The Pro*C code does not use oci. The application is expected to be a single thread. The application runs as expected when compiled and executed in 12.2. It does not work when compiled and executed using 19.3.
Our application is Pro*C code compiled in 64 bit mode against 19c. We’re calling EXEC SQL CONNECT. (the call in the generated code is sqlcxt()). Our main process just stays in the system call sigsuspend() forever, because the Oracle thread caught our SIGCHLD.
Our thread never comes out of the sigsuspend(). The threads don’t talk (the first doesn’t even know about the second one).
Below are the process steps for our application.
- Subsystem process starts and sets up a signal handler for SIGCHLD.
- Process connects to the database.
- Process blocks SIGCHLD
- The process fork/exec a child.
- The process calls sigprocmask() and then suspends waiting on the child process to exit.
- By catching the SIGCHLD
- Process unblocks SIGCHLD and proceeds.
After the 19c upgrade, Oracle creates a new thread for the subsystem process when it connects (step 2 above). The new thread will catch the SIGCHLD (from step 3). The signal is not ever seen by the main process which leaves it forever suspended waiting for the SIGCHLD.
It is a timing thing. When we put debug messages in the code to see where we are getting to, the problem does not happen. I guess writing to disk changes the timing enough to allow the signal to go to the correct thread.
Doing a ps -L on the client processes will show multiple threads for our 19c code, while doing the same thing for the same processes on 12.2 only shows a single thread.
So far It looks like the work around listed in the bugs fixed our problem. Please review the thread 4266189 above. Work around:
Disable the client statistic feature of 19c according to the following steps.
1) Setting an initialized parameter CLIENT_STATISTICS_LEVEL to OFF only on a database side.
2) Restart a database
We are not seeing the multi threads but we still do not know where OCI_THREAD is set in Oracle 19C and why did this start in 19C? Is this a major change introduced some how in 19C?