[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993182#comment-12993182
]
Rick Hillegas commented on DERBY-4741:
--------------------------------------
Thanks, Dag. Here is another attempt to summarize the user-visible behavior
after these improvements.
If an application experiences Thread interrupts, its designer should plan for
the following behavior:
1) If a Thread is interrupted inside a Derby JDBC call, then the Connection
experiencing the interrupt MAY be terminated. If the Connection is terminated,
the application will experience the following consequences:
a) The JDBC call will raise a 08000 (CONN_INTERRUPT) exception.
b) Outstanding transactional work on that Connection will be rolled back and
all of its locks will be released.
c) The Connection will not execute any further JDBC calls.
d) On return from the interrupted JDBC call, the Thread's isInterrupted()
method will report "true".
2) All other Connections will remain active. This includes other Connections
which the interrupted Thread may be using.
3) Application designers are advised to catch these 08000 exceptions, discard
the dead Connection, and restart their transaction in a new Connection.
> 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
