[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924451#action_12924451
]
Lily Wei commented on DERBY-4741:
---------------------------------
Hi Dag:
Thank you so much for the write out. All a, b, c, d points are very clear
and straight forward. Personally, I like the fact we are checking interrupt at
executeBatch, executeQuery, BasicNoPutResultSetImpl(same as timeout) and
waiting for lock area. Thank you for add the synchronized
(slaveRecoveryMonitor) and adding all the necessary release notes information.
I apply the derby-4741-a-01-api-interruptstatus. All the suites.all passed
and timing for MicroAPITest is close to clean trunk. It also passed
Derby151Test with interrupt check. Mailjdbc is still having deadlock issue.
However, like you said, it might or might not cause by the new change. I notice
some of the interrupt code is in slight different places in Embed*.java with
local initial null value. And, some of interrupt handling code are not in this
patch than the previous patch. I am assuming those code are handling machinery
of InterruptStatus that save interrupts and it will come in later patch.
I view this patch as it will benefit a lot of customers and love to help
out if I can. Thank you so much for working so hard on this.
> 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-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.
