Moving to derby-dev.
I agree with Francois here.
In a typical web based application environment where derby is supposed
to work well with various frameworks (connection pooling/ORM etc), this
issue is going to be very critical. The system will break due to these
external interrupts.
I found the following thread on the derby list, where the same problem
has been reported before.
http://mail-archives.apache.org/mod_mbox/db-derby-user/200508.mbox/[EMAIL
PROTECTED]
Another interesting thread about Java Concurrency,
http://www.nabble.com/safe-interruption-td12605694.html
Derby-2564 is also related.
My intention here is not only to make everybody aware of this issue of
such complexity and importance, but also to start discussion on how we
can deal with this. In my opinion, it is going to be difficult to
identify all the cases where such interrupts will pass through the
cracks in derby system. But, I believe, we have 2 cases (derby151 and
LogToFile.flush) surfaced now. Also, It is going to be tricky to
identify how to deal with such InterruptedExceptions, which needs to
detailed discussion.
ideas/comments ?
P.S. I am not going to miss the discussion till monday when I get back
on my email.
Mayuresh
Francois Orsini wrote:
Is this the same as DERBY-151?
Yes it sounds like it. There is a workaround with clearing the
interrupt flag on the thread but it may not always be possible to
apply this workaround if some framework is causing this and not the
application logic written by some user. In any case, Derby should not
left a database in some inconsistent state if an interrupt is issued
outside of Derby upon writing to the log for instance.
Kathey
