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 Tue, 02 Nov 2010 14:46:25 GMT

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

Knut Anders Hatlen commented on DERBY-4741:
-------------------------------------------

Hi Dag,

I went through the a-03-api patch, and I couldn't spot anything that
you've missed.

There were quite a number of places to check the interrupt
status. More than what I had expected. But I cannot think of a better
place to short-circuit it, so... Except perhaps in EmbedConnection. It
looks to me like most of the calls to restoreIntrFlagIfSeen() happen
within try blocks right after calls to setupContextStack(). Did you
consider it as an option to move the restoreIntrFlagIfSeen() calls
into restoreContextStack(), which is already called in the finally
clauses at those places? That may make the code more contained, but
perhaps the LCC isn't easily available there?

Apart from that, I only have some minor comments to the code in the
InterruptStatus class. Very minor, so feel free to ignore.

- throwIf: Unnecessary return statement.

- stackTrace: The initialValue() override does the same as the default
  implementation. So by just using a vanilla ThreadLocal object, we'd
  get the exact same behaviour, and one less class in derby.jar +
  permgen. (If the footprint issue is important, the same might be
  said for receivedInterruptDuringIO if we change its usage from a
  TRUE/FALSE check to a null/non-null check. Actually, the presence of
  a stack trace is probably a good enough indicator in itself.)

- Instead of creating an exception, fetching its stack trace and
  storing the trace, perhaps it would be easier just to store the
  exception? Then throwIf() could throw the stored exception instead
  of creating a new one and modifying its stack trace.

> 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-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-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.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, 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.


Mime
View raw message