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] Commented: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Thu, 11 Nov 2010 18:51:14 GMT

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

Knut Anders Hatlen commented on DERBY-4741:

I had a look at the b-01-nio patch, and it looked correct to me. The
stealth mode part wasn't entirely obvious, but the comments were
helpful and the code appears to be doing the right thing.

As far as I can see, the code will behave the same way as before if no
interrupt is detected. So if there are problems with the code, they
will hopefully be limited to the case where the thread is
interrupted. There's an additional container-wide synchronization on
every page read/write, though, which may possibly have a negative
effect on performance in multi-threaded environments. If that turns
out to be an issue, would it be possible to change the code to only
check restoreChannelInProgress after an exception has been thrown,
similar to what we currently do in stealth mode?

Some minor issues found in the patch:

1) Thread.holdsLock() is a static method, but all calls to it are done
on Thread.currentThread().

2) I think the checks for SQLState.INTERRUPT_DETECTED should use
getMessageId() instead of getSQLState(), since the SQLState interface,
despite its name, contains message ids and not SQLStates (although the
message id and the SQLState happen to be the same for this error).

And since INTERRUPT_DETECTED is only intended to be used internally,
would it make sense, instead of giving INTERRUPT_DETECTED a proper
SQLState and also an entry in messages.xml (which will be picked up
and translated unnecessarily later), to create a subclass of
StandardException for this error? Something like what's done with
NoSpaceOnPage, I mean. That could also make the catch blocks used to
handle this condition a little bit tidier.

3) Javadoc for RAFContainer4.readPage() should explain how the offset
parameter is supposed to be used (-1 for normal reads, actual offset
for embryonic pages)

4) The variable "whence" in awaitRestoreChannel() does not seem to be
used. Nor is its "pageNumber" parameter, I think.

> 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:,,,,,,,,,,
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4741-a-01-api-interruptstatus.diff, derby-4741-a-01-api-interruptstatus.stat,
derby-4741-a-02-api-interruptstatus.diff, derby-4741-a-02-api-interruptstatus.stat, derby-4741-a-03-api-interruptstatus.diff,
derby-4741-a-03-api-interruptstatus.stat, derby-4741-a-04-api-interruptstatus.diff, derby-4741-a-04-api-interruptstatus.stat,
derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat, derby-4741-b-01-nio.diff,
derby-4741-b-01-nio.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, InterruptResilienceTest.java, 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.

View raw message