| OCI Logon/Logoff Threading issue [message #128135] |
Fri, 15 July 2005 05:57  |
setanta
Messages: 3
Registered: July 2005
|
Junior Member |
|
|
Hi,
I'm trying to solve an OCILogon/OCILogoff problem, I'd appreciate it if anyone has any ideas.
I have a Visual C++ 7.1 project (not managed) with several threads attempting to connect to Oracle, (no more than four) which execute the OCI instructions. A single thread demonstrates no problems whatsoever, when more than one is running, I find the system throwing multiple SEH exceptions.
The classes are protected by a common critical section, and exception handling is in place. When the exceptions occur, the CPU flatlines at 100%, and no more login or logout activity can take place. The classes in question are simply multiple instances of the same class executing on one thread per class. As mentioned, when I have only one thread executing, I have no problems performance or behaviour.
I'm using the Oracle 9 client library. The Critical Section which protects the class, is a static const so that only one instance is shared across all threads, meaning that all OCI calls
are serialized. I have also tried (out of sheer exasperation) using their own individual class level sections, and passing a single section to all candidates as a parameter, of course this made no difference. In addition and would kind of defeat the purpose of multithreading my app in the first place.
I also tried creating a class which provided logon/logoff functions and passing that in the constructor of the main class. This meant that only one instance would make serialized calls to OCI for logon/logoff purposes. This did not work either, making the OCI appear unsafe in a threaded environment, which I simply refuse to believe.
If anyone can help I'd really appreciate it.
Thanks
setanta
|
|
|
|
| Re: OCI Logon/Logoff Threading issue [message #128942 is a reply to message #128135] |
Thu, 21 July 2005 05:56  |
setanta
Messages: 3
Registered: July 2005
|
Junior Member |
|
|
After much meddling about, single-threaded and multi-threaded testing, even abandoning the OCILogon/OCILogon methods for direct SessionBegin/SessionEnd methods, it turns out that our oracle names server was the culprit.
Ok, it doesn't quite explain the mysterious thread abandonment and destruction of the OCI api, not to mention a poor nod to exception handling and failure-safety. Although I suppose whatever is wrong with our names server is contributing to the failures in client-side oci calls.
Ultimately I ended up adding the correct details into TNSNames.ora, and sqlnet.ora, and I can make brute-force connect/disconnect cycles to my heart's content without a single exception to be seen.
Anyway, I hope this helps someone else if they should be unfortunate to come across this problem. Cheers.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
