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, 02 Nov 2010 15:56:29 GMT

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

Dag H. Wanvik commented on DERBY-4741:
--------------------------------------

Thanks for looking at the patch, Knut!

> Except perhaps in EmbedConnection. It looks to me like most of the calls to restoreIntrFlagIfSeen()
happen within try blocks right after calls to setupContextStack(). Did you consider it as
an option to move the restoreIntrFlagIfSeen() calls into restoreContextStack(), which is already
called in the finally clauses at those places?

I did try to put the call into the finally,although not into restoreContextStack. I found
that didn't always work, since during error handling *before* we get to the finally block,
calls to handleException(throwable) will depending on severity, potentially take down the
connection (and database), causing us to lose the lcc.  Hence I had to move it back to just
before normal return, and use the no-args variant of restoreIntrFlagIfSeen handling inside
the error handling code (cf changes in TransactionResourceImpl#handleException).

> - throwIf: Unnecessary return statement.

Agreed, will fix that :)

> - stackTrace: The initialValue() override does the same as the default implementation.
So by just using a vanilla ThreadLocal object, we'd get the exact same behaviour, and one
less class in derby.jar + permgen.

Agreed.

>  (If the footprint issue is important, the same might be said for receivedInterruptDuringIO
if we change its usage from a TRUE/FALSE check to a null/non-null check. Actually, the presence
of a stack trace is probably a good enough indicator in itself.)

Yes and yes. Originally I used the stacktrace just for debugging with sane, I think.

> - Instead of creating an exception, fetching its stack trace and storing the trace, perhaps
it would be easier just to store the exception? Then throwIf() could throw the stored exception
instead of creating a new one and modifying its stack trace.

That's good simplication, yes.


> 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: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0
>            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-a-03-api-interruptstatus.diff,
derby-4741-a-03-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.


Mime
View raw message