[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992159#comment-12992159
]
Rick Hillegas commented on DERBY-4741:
--------------------------------------
Hi Dag,
Thanks for the functional spec. I am trying to wrap my mind around what
application writers can expect. Is the following a fair summary?
1) If the Thread is interrupted while running outside Derby (that is, not
inside a JDBC call), then Derby does not field the interrupt. The Connection
remains alive and Thread.isInterrupted() will not be touched by Derby.
2) On the other hand, if the Thread is interrupted while running inside a Derby
JDBC call...
a) The Connection may be killed and have to be restarted. If the Connection is
killed, then Thread.isInterrupted() will be true.
b) Alternatively, it is also possible that the interrupt will not kill the
Connection. In this case, the state of Thread.isInterrupted() is unclear to me.
I am having a hard time reconciling "will be still be set...when exiting from
the Derby API method" with "it is not deterministic whether the flag will
remain set or be cleared on return".
Thanks!
> 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
