How can I set SO_TIMEOUT on the sockets used by the JDBC 2005 driver?

Hello,

One of our customers is experiencing a problem that makes me think there is a network problem, because we make a request and never return from the driver, but the transaction is still open on the server awaiting the next command (and holding locks blocking other processes). I see a number of other driver writers have described similar problems, and their "workaround" is to set SO_TIMEOUT on the sockets (setSoTimeout) they create which is a last defense so that the transaction won't block forever.

I do not see this in the API documentation- how can I set this Many other drivers use a connection string parameter, do you offer the same

Is there any logging I can enable that can show me for sure that the driver is waiting indefinately on socket.read (thats not terribly expensive)

Thanks,

Steve

Thanks but I need clarification-

The description of this method states that this is the amount of time the query will be allowed to execute. Is this enforced by the client or by the server

Also- I see in the connection string properties there is a lock timeout specified as:

The number of milliseconds to wait before the database reports a lock time-out. The default behavior is to wait indefinitely. If it is specified, this value is the default for all statements on the connection. Note that Statement.setQueryTimeout() can be used to set the time-out for specific statements. The value can be 0, which specifies no wait.

So this makes me think that setQueryTimeout and lock timeout connection property are the same thing, but they are NOT the same thing. In my case, our customer is experiencing some kind of network condition that is not being propegated back to our code. The result is we have a transaction that is open (blocking) on the database that is waiting for a commit or rollback, but the driver never returns to our code. So this transaction ends up blocking other transactions. We have set lock timeout on the connection and this results in the second, third, etc. transactions to eventually fail with a lockTimeout exception, but the original transaction stays open still blocking. So what we want is a socket timeout (ex. SO_TIMEOUT in win32 api or socket.setSoTimeout in java) to be able to set this.

If setQueryTimeout will accomplish then great, but if this just ends up adding a lock timeout then this wont solve the problem. Note as well that whatever this magical network condition is seems to be a problem for many database drivers running in windows (jtds, ibm db2, etc) and they all implement a socket timeout as a workaround.

Thanks,

Steve