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 Wed, 27 Oct 2010 17:00:21 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-a-02-api-interruptstatus.stat

Uploading derby-4741-a-02-api-interruptstatus, an improved version of

I went over the usages of restoreIntrFlagIfSeen in the API and
reevaluated where it is possible to supply the lcc and where it is not
safe: the intention is that if we stored the interrupt status flag in
a lcc we should be recover it from there before returning to the user
app and, similarly, if we stored the interrupt status flag in a thread
local variable because an lcc was not available, we should recover it
from there. It turns out it is not always obvious to determine where to
look in the API methods.

API methods vary with repect to whether they:

    a) synchronize on the connection or not, cf. possible bugs
       see DERBY-4129, even when accessing store.

    b) call setupContextStack or not (this is what lets us find the
       lcc down in store using ContextService.getContextOrNull)

    c) clean up when errors occur by calling handleInterrupt(t), cf my
       comment on DERBY-4129, e.g. EmbedClob. The cleanup can lead to
       a connection closing if severity is high, setting its lcc to

    d) even if an API method doesn't call setupContextStack, it may be
       called indirectly from a context that does set it up, cf.
       part of a trigger on an insert.
When a connection (or database) is being closed down, we need to be
careful so that we catch the lcc while it is still available. When
cleaning up errors in TransactionResourceImpl#handleException we do
not directly know if an lcc is available or not.

The upshot of all this is that unless we are sure we have a valid lcc
(i.e. we see statically that setupContextStack has been called), we
instead call restoreIntrFlagIfSeen *without* an lcc argument. The
zero-arg variant calls getContextOrNull to see if a lcc is available
for the thread, falling back to the thread local if not. So, in
effect, the lcc variant is an optimization, but it does cover the
methods for which performance could be an issue, I think.

The new patch covers LOB ands CLOB as well, and is ready for review.

Regressions ran ok.

> 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-a-01-api-interruptstatus.diff, derby-4741-a-01-api-interruptstatus.stat,
derby-4741-a-02-api-interruptstatus.diff, derby-4741-a-02-api-interruptstatus.stat, derby-4741-all+lenient+resurrect.diff,
derby-4741-all+lenient+resurrect.stat, 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