db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Sun, 10 Oct 2010 19:07:32 GMT

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

Knut Anders Hatlen edited comment on DERBY-4741 at 10/10/10 3:07 PM:
---------------------------------------------------------------------

Thanks Dag. The proposed plan sounds good to me.

As to what to do with the interrupt status after a retry, I'd be happy as long as we always
either fail or preserve the interrupt status. I don't have any strong opinions on whether
or not we should set the interrupt flag when raising the exception. I see that the pre-NIO
methods that may be interrupted (wait, sleep, join) will throw an exception and *clear* the
interrupt status, whereas the interruptible NIO methods will throw an exception and *set*
the interrupt status, so the precedence from the class library is ambiguous. I agree, though,
that the user's intent is probably to stop the thread, and then preserving the interrupt status
sounds reasonable in order to prevent that the thread just runs to the next blocking call
and gets blocked there.

      was (Author: knutanders):
    Thanks Dag. The proposed plan sounds good to me.

As to what to do with the interrupt status after a retry, I'd be happy as long as we always
either fail or preserve the interrupt status. I don't have any strong opinions on whether
or not we should set the interrupt flag raising the exception. I see that the pre-NIO methods
that may be interrupted (wait, sleep, join) will throw an exception and *clear* the interrupt
status, whereas the interruptible NIO methods will throw an exception and *set* the interrupt
status, so the precedence from the class library is ambiguous. I agree, though, that the user's
intent is probably to stop the thread, and then preserving the interrupt status sounds reasonable
in order to prevent that the thread just runs to the next blocking call and gets blocked there.
  
> 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-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,
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