Thread interrupt

[Jerry]

We have a product that uses multiple threads to load data into a
database. If there is a problem, the controlling thread sends an
interrupt to each of the threads to stop processing. Apparently the
interrupt is ignored by H2 so any threads that are waiting on a lock
never see the interruption and don't know to shutdown. I saw a
discussion thread from 2007 on this, but nothing since. Is there an
open issue with properly handling a thread interrupt request?

Thanks!

[Thomas Mueller]

Hi,

Do you think "properly" means the current query must be stopped? Why
do you think so?

Did you know statements can be canceled using Statement.cancel()?

Regards,
Thomas

[Jerry]

From the book:
_Java Concurrency in Practice_
by Brian Goetz, et. al.

Chapter 5, section 5.4

Here is a link:

http://codeidol.com/java/java-concurrency/Building-Blocks/Blocking-and-Interruptible-Methods/

This is well worth reading (actually the whole book is...), but in
particular this statement is there:

"But there is one thing you should not do with InterruptedException--
catch it and do nothing in response. This deprives code higher up on
the call stack of the opportunity to act on the interruption, because
the evidence that the thread was interrupted is lost."

So yeah, I guess by properly, I mean you should stop the query. If you
don't at least reset the interrupt state, you are not in compliance
with good concurrency practice. Problem is, if you set the interrupt
state (as one alternative suggested in this chapter), when your
doLock() method (where I am seeing this issue) loops and tries the
wait again it will immediately throw the exception again--probably not
what needs to be done. I also don't see anywhere in the doLock()
method loop that checks to see if the statement was cancelled, so the
statement cancel would not stop the processing here anyway.

And I also see that the InterruptedException is ignored in a lot of
places, which is in opposition to what Goetz says should happen. So
this is really a bigger concurrency handling problem than just in the
doLock() method I am looking at.

Please don't interpret an adversarial tone in my comments... I just
want to give you some ideas based on how the Java API designers
intended for this to be handled.

For what it's worth, I checked the Derby (I know - bad word) source
and they throw a CONN_INTERRUPT (08000) exception whenever interrupted.

[Thomas Mueller]

Hi,

> _Java Concurrency in Practice_

Thanks.

H2 supports canceling statements using Statement.cancel(). I will add
support for Thread.interrupt to the roadmap, but I'm not sure when I
will have time to implement it.

Regards,
Thomas

[Steve McLeod]

Adding my thoughts... (and yes, I've read JCIP several times - a great
book).

In general, using JDBC sends a query to another process, usually
running on a separate server (such as Oracle, Postgresql). The only
sure way to stop a long-running query is using statement.cancel().

Thread.interrupt as a way to stop a query makes sense for an embedded
database like H2, but is not an approach you can rely on in general in
JDBC.

In my experience with Oracle, even if your Java client software
completely exits cleanly with all threads ended, an incomplete query
still continues running on Oracle until complete.

So in general, use statement.cancel() in JDBC. Unfortunately this
requires convoluted code, as the interrupting thread needs a handle to
the statement in the thread running the long-running query.





On Nov 18, 8:25 am, Thomas Mueller <thomas.tom.muel...@gmail.com>
wrote: