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