Thread.interrupts should be the call to wake up a thread. This happens even, if a Java-App is blocked in a IO-Operation.
Be warned. Doing this may or may not work, and is usually
both surprising and not what was intended, and also usually
different for different operating systems.
I'm getting disenchanted again :-(

Is Thread.interrupt() even safe, when i use the native libraries?
I think, that a native library must explicitly check and handle Thread.interrupt() calls.
... or do it sometimes or not at all, as the native
routines from Sun do. Interestingly I/O operations are
explicitely cited by Sun as being no good targets for Thread.interrupt().
That makes it even worse.

Does the JDBC-Driver handle the InterruptedException and InterruptedIOException properly?
As the JDBC Driver internally neither uses the 'nio', nor does it call one of the 'wait' or 'join' or 'sleep' functions, there is no place where this exceptions may occur.
How about an InterruptedIOException while doing read/write on Sockets?

Anyway, Statement.cancel() is implemented, and usually works. I assume
you wanted to do something like that.
With my current structure, i don't know the Statement that's currently executed. But that wouldn't help much.
I'm targetting on the Socket-IO which may block for a relatively long time if the connection is broken. Even a Socket.close() can block if SO_LINGER is on.

_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to