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