Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 78030 invoked from network); 18 Oct 2010 23:50:55 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Oct 2010 23:50:55 -0000 Received: (qmail 27940 invoked by uid 500); 18 Oct 2010 23:50:55 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 27918 invoked by uid 500); 18 Oct 2010 23:50:55 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 27911 invoked by uid 99); 18 Oct 2010 23:50:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Oct 2010 23:50:55 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Oct 2010 23:50:54 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o9INoYtv016994 for ; Mon, 18 Oct 2010 23:50:34 GMT Message-ID: <1135271.33741287445834446.JavaMail.jira@thor> Date: Mon, 18 Oct 2010 19:50:34 -0400 (EDT) From: "Dag H. Wanvik (JIRA)" 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922362#action_12922362 ] Dag H. Wanvik commented on DERBY-4741: -------------------------------------- The approach seems to work. This should take care of the performance worries for using InterruptStatus#throwIf in API methods. Sometimes there is no lcc, e.g when creating a new database; we could then fall back on the dedicated thread local variable, cf. during EmbedConnection constructor's call to createDatabase. Another note: undo is still vulnerable, e.g. an interrupt during rollback, usage of StorageRandomAccessFile in cf. Scan.java, cf. ------------ BEGIN SHUTDOWN ERROR STACK ------------- ERROR XSLA3: Log Corrupted, has invalid data in the log stream. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:279) at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:216) at org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939) at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949) at org.apache.derby.impl.store.raw.xact.XactContext.cleanupOnError(XactContext.java:119) at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(ContextManager.java:333) at org.apache.derby.impl.jdbc.TransactionResourceImpl.cleanupOnError(TransactionResourceImpl.java:419) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:337) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2277) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1325) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1683) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:305) at InterruptTest$WorkerThread.run(InterruptTest.java:263) Caused by: java.io.InterruptedIOException at java.io.RandomAccessFile.read(Native Method) at java.io.RandomAccessFile.readInt(RandomAccessFile.java:721) at java.io.RandomAccessFile.readLong(RandomAccessFile.java:758) at org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:394) at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204) (roll-back happens here due to the test trying to insert a duplicate after a commit has been interrupted) > 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, 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.