[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4741:
---------------------------------
Attachment: derby-4741-nio-container+log+waits+locks+throws.stat
derby-4741-nio-container+log+waits+locks+throws.diff
Uploading another experimental patch,
derby-4741-nio-container+log+waits+locks+throws.
The change now is
- some further generalizing of recovery logic in RAFContainer4, the readPage
logic was missing some stuff I had added for writePage
- introduced InterruptTest#throwIf, which is a helper method to check & reset
the thread's interrupt status and throw an SQLException (08000 for now) if set.
- added throwIf next to Query timeout logic in
BasicNoPutResultSetImpl#checkCancellationFlag
- added throwIf before all returns in impl/jdbc/*.java in methods which call
(directly or indirectly) handleException(t), typically this pattern:
:
InterruptTest#throwIf()
return;
} catch (Throwable t) {
throw handleException(t);
This will make sure Derby throws if it ever did see an interrupt during
operation, which was intercepted for safety and postponed till a "safe place".
This is a "catch-all", though, and I'll look for other places closer to the
originating sites (container I/O, log I/O) so Derby could throw earlier.
For example, commit can now throw if we see an interrupt during writing to log,
cf. call to throwIf in EmbedConnection#commit.
Currently all interrupts throw 08000 which is session level, and none yet set
the thread's intr flag. I will go over all usages of 08000 and set the flag
next if we agree that's the right thing to do. Note that Derby151Test fails
now, but InterruptTest should work and report all interrupts Derby see (some
interrupts happen while the test is in application code; this is called out in
the test's results). Btw, InterruptTest is not yet a JUnit test..
The patch is getting a bit large and unwieldy now, but not to worry, the patch
is just a proof of concept, I'll break it down into smaller pieces before any
proposed commit. Rerunning regressions.
I see Lily would prefer statement level error, rather than session level. I am
sticking to session level for now since that's what the exisiting 08000
currently is. I'll go over the remaining *existing* usages of 08000 which I
didn't already replace with "InterruptStatus.setInterrupted" + retry logic. If
all are ok to replace, we could probably choose to change the exception to
statement level rather than session level. If not, it might be confusing to
have two kinds of SQLExceptions for interrupts, with different severity...
> 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+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, 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.
