[
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.
