[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923678#action_12923678
]
Dag H. Wanvik commented on DERBY-4741:
--------------------------------------
Hei Lily, thanks for your continued interest in this issue!
> Will you elaborate on that in turn of the new patch behavior please?
My present thinking is that the goal should be:
a) the best user experience will be that for operations
(technically JDBC API calls), which detect an interrupt, but
manage to retry and continue the operation, and for which we do
not cut the operation short, because there is no natural
point at which to interrupt it, or we deem it to be so short in
duration that we might as well see it through, we:
- do not throw an exception
- restore the interruped status flag just prior to return from
the operation (JDBC API call)
b) for operations that we actually cut short due to the interrupt,
see current enumeration below, we
- throw SQLException 08000, session level (we might change this
severity later as discussed)
- also resurrect the interrupt status flag just prior to return
from the operation (JDBC API call)
c) for operations, which detect an interrupt, but
manage to retry and continue the operation, but eventually throw
an SQLException (not 08000, some other), we do as in a):
- restore the interruped status flag just prior to return from
the operation (JDBC API call)
d) Operations that we may currently cut short if we see an interrupt
early enough:
- executeBatch (we check between each statement)
- executeQuery (we check in the present
BasicNoPutResultSetImpl#checkCancellationFlag in the same
location that we check for timeout currently)
- while waiting for a lock, cf. LockSet.java,
ConcurrentLockSet.java
Further suggestions for good places to check and throw are welcome :)
> .. synchronized (slaveRecoveryMonitor): And, I add it to my client
> space and run some tests. It seems not harming anything.
Good, we'll add it then.
> Will we add a note somewhere about the code not cover for this
> interrupt handling?
For the time being, we can make notes in this JIRA issue, but
eventually I suspect we will want to make a release note to describe
the improvements, and what remains to be done. You are right that
there is a lot of work, it is also hard to test, unfortunately.
> 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-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.
