db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject thread interrupts and Derby I/O
Date Tue, 04 Nov 2008 00:43:22 GMT
I am looking a problems caused by interrupts being delivered to to Derby 
threads from outside Derby code (for example see DERBY-151).  In all of 
the cases that I have had to
do support on the application didn't actually want to interrupt Derby, 
and often did not even know their code (or some other code they had 
embedded) was doing the interrupt.  As the test case in DERBY-151 shows
it is very easy to cause this, just call Thread.

Prior to our use of channel based I/O in the logging system and the data 
base I/O these interrupts would not affect the I/O at all.  Now if an
interrupt is delivered to a thread that will call Derby code before the
thread's isInterrupted flag is cleared any channel based I/O will fail.
So customers moving up to later Derby versions are seeing this as a
regression.

So after looking at this a little should Derby try to do it's I/O 
somehow, basically somehow ignoring the interrupt?  I think the only
way to continue would be to clear the interrupt and then doing work
to either reget the channel, and possibly reopen the file.  This was
the path was making my way down at first, but then wondered if this was
a good behavior for an embedded application.  Any opinions?

In most cases if
Derby gets an interrupt error it is going to treat it as unrecoverable
and shut down the database.  The errors in this case could definitely
be improved, as they mostly point the wrong cause and lead user to think
the db is corrupted.  In all the interrupt based shutdowns that I have
seen the db will boot fine as long as the booting thread has cleared the
interrupted flag.  Unfortunately I think it would be a major project to
figure out how to only affect the current thread in such a I/O failure
as there are low level cross thread dependencies on the I/O working so
it is not as simple as just failing the current thread (especially hard 
are reads and writes to the database recovery log which may contain work
for more than just the current thread).



Mime
View raw message