Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27139224.75321286801295389.JavaMail.jira@thor>
Date: Mon, 11 Oct 2010 08:48:15 -0400 (EDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4741) Make Derby work reliably in the
 presence of thread interrupts
In-Reply-To: <13345993.330341278959929752.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Dag H. Wanvik commented on DERBY-4741:
--------------------------------------

Thanks, Knut! I agree it's a bit weird that the JRE is a little schizophrenic about the interrupt flag. I think we should try to be consistent when we throw, no matter where/after which Java API call Derby detects it. If we do retain the interrupt flag, I think it adds to the argument for making the exception session-level, since the user would need to undertake some cleaning up anyway, or else the next Derby call would fail as well. Probably this would be the use case for connection pools. As to arguments for making the error statement level, I guess if one just wants to stop a run-away query, one would possibly prefer that just the statement failed.  A thing to consider here is the new JDBC 4.1 method Connection#abort:
This would be the future portable way of stopping a run-away transaction. It will also close the the connection.

This patch passed regressions, for what it's worth.

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