[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992279#comment-12992279
]
Dag H. Wanvik commented on DERBY-4741:
--------------------------------------
Thanks for reading the spec, Rick.
1) Not true. If the flag is set at the time the Derby API call, Derby may
throw. Derby can't know exactly when the thread was interrupted, it can only
notice it by either a) seeing Java API methods return exceptions, or b) testing
the flag explicitly. We do not test the flag on Derby API method entry. We heed
(i.e. throw) interrupts in the specified situations enumerated in the spec.
2b) The flag will remain set when exitting from in all cases. The note about
deterministic only applies if the flag *is attemped cleared* by another thread
while the Derby API call is still executing. If we ever saw an interrupt and
had to clear it to make execution continue, e.g. for NIO, we set it again at
Derby API method exit, whether we throw or not. This means that any attempt to
clear it while Derby is executing could be lost, depending on exactly when the
clearing attempt was made, hence "non-deterministic".
> Make embedded 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: InterruptResilienceTest.java, MicroAPITest.java,
> 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-a-04-api-interruptstatus.diff,
> derby-4741-a-04-api-interruptstatus.stat,
> derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat,
> derby-4741-b-01-nio.diff, derby-4741-b-01-nio.stat, derby-4741-b-02-nio.diff,
> derby-4741-b-02-nio.stat, derby-4741-b-03-nio.diff, derby-4741-b-03-nio.stat,
> derby-4741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff,
> derby-4741-c-01-nio.stat, derby-4741-kristians-01.diff,
> 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-4741-raf-stresstest-1.diff, derby-4741-raf-stresstest-1.stat,
> derby-4741-raf-stresstest-2.diff, derby-4741-raf-stresstest-2.stat,
> derby-4741-raf-stresstest-3.diff, derby-4741-raf-stresstest-3.stat,
> derby-4741-raf-stresstest-4.diff, derby-4741-raf-stresstest-4.stat,
> derby-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.stat,
> derby-4741-sleeps-waits-2.diff, derby-4741-sleeps-waits-2.stat,
> derby-4741-sleeps-waits-3.diff, derby-4741-sleeps-waits-3.stat,
> derby-4741-testBatchInterrupt-b.diff, derby-4741-testBatchInterrupt.diff,
> derby-4741-testQueryInterrupt.diff, derby-4741-testQueryInterrupt.stat,
> derby.log, derby.log, interrupts-fs.html, interrupts-fs.html, 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 for extra concurrency.
> If a 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 store can be left in an inconsistent
> state, although no data is corrupted, and we therefore have to return a
> database level error to perform shutdown and recovery. This means the
> applications can no longer access the database while a shutdown and reboot
> including a recovery is taking place.
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
