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 Derby work reliably in the presence of thread interrupts
Date Thu, 21 Oct 2010 22:49:18 GMT

    [ 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.


Mime
View raw message