db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Fri, 08 Oct 2010 17:52:31 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-4741:
----------------------------------


so far your approach seems fine to me, and I think will help a lot of customers.  I was wondering
if
you have a high level goal.  Basically what should derby do when it encounters an interrupt.

I think it should always throw some sort of error back to caller, and would be nice if the
error or 
the nested error indicated clearly that it is being thrown because of a thread interrupt.
 Many times
when supporting this issue it takes awhile for the user to realize that they are the ones
generating
the interrupt.

I think the error should not be database level, and with your retry on I/O and log it seems
like we
can avoid that.  I am not sure if it should be session or statement level,
I am leaning to it being session level, but would like to see a discussion.  I know often
users are
doing the interrupt to stop a thread.  

Ultimately do you plan on always reenabling the interrupt after retrying or getting to a safe
place?

We should definitely throw an error in the case of an interrupt during a lock wait, this seems
like the
one valid case to send an interrupt to derby if a user thinks it is waiting too long.  Hopefully
you can
code it to handle it, do processing, get to safe spot and then throw an error indicating a
real user 
interrupt during a wait.  

Something to think about in the error throwing is the background thread.  What should we do
if
it encounters an interrupt.  Throwing an error there might shutdown the db, i am not sure
what it
does at top level with an error.



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