db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Mon, 25 Oct 2010 14:47:19 GMT

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

Dag H. Wanvik edited comment on DERBY-4741 at 10/25/10 10:45 AM:
-----------------------------------------------------------------

Hi Lily, thanks for test driving the patch :) I really appreciate your help looking at this
work. Having another set of eyes on this is good, the change are a bit cross cutting and affect
much existing code, so it's good to have someone double checking the changes. Two comments:

- if the mailjdbc test still deadlocks, I doubt it can be due to this patch, since it doesn't
really change any behavior, it just installs the machinery for the behavior changes to come
in later patches, as you presumed.

- the difference is EmbedBlob with local initial null is just some cruft from an experiment
I did with trying to place restoreIntrFlagIfSeen in a finally block. This didn't work out
since, error handling may close the connection and with it the lcc, so the check would happen
too late. (The current method is to check before return and in the error handling code itself).
I'll revert that change, thanks for noticing.

My main concern with this patch currently is to verify that I have found all the ways control
can return to the user app after Derby code has had control, and possibly set the interrupt
status flag. A case in point is the Blob methods that don't require a connection, e.g. EmbedBlob#getBytes
if the lob is materialized, we call control.read: if we see an interrupt inside the read,
the flag would get stored in a thread local variable, since there is no lcc, so I'll I need
to add a call to no-args version of restoreIntrFlagIfSeen() there. EmbedClob needs analysis,
too.

      was (Author: dagw):
    Hi Lily, thanks for test driving the patch :) I really appreciate your help looking at
this work. Having another set of eyes on this is good, the change are a bit cross cutting
and affect much existing code, so it's good to have someone double checking the changes. Two
comments:

- if the mailjdbc test still deadlocks, I doubt it can be due to this patch, since it doesn't
really change any behavior, it just installs the machinery for the behavior changes to come
in later patches, as you presumed.

- the difference is EmbedBlob with local initial null is just some cruft from an experiment
I did with trying to place restoreIntrFlagIfSeen in a finally block. This didn't work out
since, error handling may close the connection and with it the lcc, so the check would happen
too late. (The current method is to check before return and in the error handling code itself).
I'll revert that change, thanks for noticing.

My main concern with this patch currently is to verify that I have found all the ways control
can return to the user app after Derby code has had control, and possibly set the interrupt
status flag. A case in point is the Blob methods that don't require a connection, e.g. EmbedBlob#getBytes
if the lob is materialized, we call control.read: if we see an interrupt inside the read,
the flag would get stored in a thread local variable, since there is no lcc, so I'll I need
to add a call to no-args version of restoreIntrFlagIfSeen() there.
  
> 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-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