db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Thu, 14 Oct 2010 02:13:33 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-4741:

    Attachment: derby-4741-nio-container+log+waits+locks+throws.stat

Uploading another experimental patch, derby-4741-nio-container+log+waits+locks+throws.

The change now is 
- some further generalizing of recovery logic in RAFContainer4, the readPage logic was missing
some stuff I had added for writePage
- introduced InterruptTest#throwIf, which is a helper method to check & reset the thread's
interrupt status and throw an SQLException (08000 for now) if set.
- added throwIf next to Query timeout logic in BasicNoPutResultSetImpl#checkCancellationFlag
- added throwIf before all returns in impl/jdbc/*.java in methods which call (directly or
indirectly) handleException(t), typically this pattern:
} catch (Throwable t) {
      throw handleException(t);
This will make sure Derby throws if it ever did see an interrupt during operation, which was
intercepted for safety and postponed till a "safe place". This is a "catch-all", though, and
I'll look for other  places closer to the
originating sites (container I/O, log I/O) so Derby could throw earlier. 

For example, commit can now throw if we see an interrupt during writing to log, cf. call to
throwIf in EmbedConnection#commit.

Currently all interrupts throw 08000 which is session level, and none yet set the thread's
intr flag. I will go over all usages of 08000 and set the flag next if we agree that's the
right thing to do. Note that Derby151Test fails now, but InterruptTest should work and report
all interrupts Derby see (some interrupts happen while the test is in application code; this
is called out in the test's results). Btw, InterruptTest is not yet a JUnit test..

The patch is getting a bit large and unwieldy now, but not to worry, the patch is just a proof
of concept, I'll break it down into smaller pieces before any proposed commit. Rerunning regressions.

I see Lily would prefer statement level error, rather than session level. I am sticking to
session level for now since that's what the exisiting 08000 currently is. I'll go over the
remaining *existing* usages of 08000 which I didn't already replace with "InterruptStatus.setInterrupted"
+ retry logic. If all are ok to replace, we could probably choose to change the exception
to statement level rather than session level. If not, it might be confusing to have two kinds
of SQLExceptions for interrupts, with different severity...

> Make Derby work reliably in the presence of thread interrupts
> -------------------------------------------------------------
>                 Key: DERBY-4741
>                 URL: https://issues.apache.org/jira/browse/DERBY-4741
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,,,,,,,
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4741-nio-container+log+waits+locks+throws.diff, derby-4741-nio-container+log+waits+locks+throws.stat,
derby-4741-nio-container+log+waits+locks-2.diff, derby-4741-nio-container+log+waits+locks-2.stat,
derby-4741-nio-container+log+waits+locks.diff, derby-4741-nio-container+log+waits+locks.stat,
derby-4741-nio-container+log+waits.diff, derby-4741-nio-container+log+waits.stat, derby-4741-nio-container+log.diff,
derby-4741-nio-container+log.stat, derby-4741-nio-container-2.diff, derby-4741-nio-container-2.log,
derby-4741-nio-container-2.stat, derby-4741-nio-container-2b.diff, derby-4741-nio-container-2b.stat,
derby.log, xsbt0.log.gz
> When not executing on a small device VM, Derby has been using the Java NIO classes java.nio.clannel.*
for file io.
> If thread is interrupted while executing blocking IO operations in NIO, the ClosedByInterruptException
will get thrown. Unfortunately, Derby isn't current architected to retry and complete such
operations (before passing on the interrupt), so the Derby database can be left in an inconsistent
state and we therefore have to return a database level error. This means the applications
can no longer access the database without a shutdown and reboot including a recovery.
> It would be nice if Derby could somehow detect and finish IO operations underway when
thread interrupts happen before passing the exception on to the application. Derby embedded
is sometimes embedded in applications that use Thread.interrupt to stop threads.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message