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] Commented: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Tue, 19 Oct 2010 21:04:29 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922716#action_12922716

Dag H. Wanvik commented on DERBY-4741:

I feel pretty confident the main approach will improve things  by now, so I'll upload a final
version of the experimental patch, and the start producing incremental patches for commit
roughly in the following order:

a) hooks in the APIs to resurrect interrupt flags before we return to the user's app on the
basis of info collected during operation, the new util class InterruptStatus, which is a collection
of methods to save away and resurrect interrupt flags, and throw an interrupt SQLexception.
I intend to *not* throw any exception if the API method ran to completion, just resurrect
the flag.
b) the modified RAFContainer4 stuff for reading and writing db cache pages safely with NIO.
c) the modified DirRandomAccessFile4 stuff + log retries for safe operation of log writing
d) stop execution if intr seen within a batch, when checking query timeout, and when seeing
intr while waiting for locks
e) make undo safe
f) time permitting, make boot and recovery interrupt safe.

Please let me know if there any objections or suggestions to this plan! Whether all this gets
ready for 10.7 is a possible issue, but hopefully we should not behave worse the before at
any step.

> 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, derby.log, MicroAPITest.java, 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