db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4741) Make embedded Derby work reliably in the presence of thread interrupts
Date Fri, 11 Feb 2011 00:38:57 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993282#comment-12993282
] 

Dag H. Wanvik commented on DERBY-4741:
--------------------------------------

> 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:

To be even more precise: "If a Thread is interrupted and the flag is not cleared before entering
a Derby JDBC call *or* the thread is interrupted while 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.

Yes

> 
> b) Outstanding transactional work on that Connection will be rolled back and all of its
locks will be released.

Yes

> c) The Connection will not execute any further JDBC calls.

Yes

> 
> d) On return from the interrupted JDBC call, the Thread's isInterrupted() method will
report "true".

Yes. 

If Derby does not throw, the Thread's isInterrupted() method will also report "true".

> 2) All other Connections will remain active. This includes other Connections which the
interrupted Thread may be using.

Yes, at least until such time as the thread, still having its interrupted flag set, tries
to use another connection, in which case, this connection is also subject to termination.

> 
> 3) Application designers are advised to catch these 08000 exceptions, discard the dead
Connection, and restart their transaction in a new Connection. 

*And* clear the interrupted flag of the thread before proceeding with another Derby connection,
preferably!

The "MAY" presently means: 
    if a query fetches rows from a base table *after* the interrupt has occurred, or
    a new element in a batched statement is attempted executed *after* the interrupt has occurred,
or
    an interrupt is received *while* waiting for a lock.

In other cases, it is ignored.
.
Note the slight difference above, between *after* and *while*. I have clarified this in a
new revision.



> 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

       

Mime
View raw message