|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Execute_query causes hang in db connection [message #357907 is a reply to message #339140] |
Fri, 07 November 2008 02:51   |
seim
Messages: 3
Registered: November 2008
|
Junior Member |
|
|
Hi, I have got the same problem and am just going to solve it for my db module.. After some time of digging on the web, i found only two interesting web sites:
1) http://www.experts-exchange.com/Database/Oracle/Q_10187879.html
"You can always poll the connection using a some kind of a timer mechanism.
For instance, set a thread in you program to check the tcp/ip connection to the host (using ICMP messages - aka ping or even tnsping) every x seconds.
Despite the network overhead, it seems like the only way to achieve what you're asking for(since you can't get it directly from Oracle)."
2) http://www.akadia.com/services/ora_net8_taf.html
"In addition to what gets preserved and lost during a failover, there are some connectivity issues to worry about. If a node goes down, your application may not notice it, and TAF may not be triggered until your application attempts to execute another SQL statement. A hung listener might cause a client to hang during a connection attempt. In that case, the client will never get a chance to attempt a connection to the backup instance. If the primary instance is up, but in an indeterminate state (such as during a startup or shutdown) client connections will fail, but not in a way that causes TAF to be triggered. Using ALTER SESSION to kill a client connection will also prevent TAF from being triggered. "
Now I'll try following:
- make some threads just for periodical tests executing 'SELECT 1 FROM DUAL' and hope, that after more failures the hanging ones will wake up
- make some proxy thread controlling the worker's thread and watching some timeout for killing the worker
|
|
|
|
| Re: Execute_query causes hang in db connection [message #358103 is a reply to message #357907] |
Sat, 08 November 2008 10:20 |
seim
Messages: 3
Registered: November 2008
|
Junior Member |
|
|
"- make some threads just for periodical tests executing 'SELECT 1 FROM DUAL' and hope, that after more failures the hanging ones will wake up"
First idea doesn't seem functional. When using SCP (StatelessConnectionPool), SCP generates Connection* objects without any hesitation after connection lost and executing Statements* via this Connection* objects hangs in as much threads as you'll try to use. This situation persists for 30minutes (system TCP settings).
- make some proxy thread controlling the worker's thread and watching some timeout for killing the worker
If you have to write a robust system and need exactly result of a database operation or error (or hint about failure), I thing this is the only way, how to do it with the hanging thread behaviour..n 
Another notes:
- if you want to create Environment* and SCP* instances, the connection to DBS must be OK, or you'll get immediately an error
- if the connection became broken, your instances of Env & SCP are no longer usable (after connection restoration yea, but you'll save some timeouts if you don't register and test the global database connection state) => perhaps better would be to release them, a peridically try to get new ones..
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
