>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. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
