You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2011/01/05 18:26:54 UTC
[jira] Issue Comment Edited: (DERBY-4741) Make Derby work reliably
in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977862#action_12977862 ]
Dag H. Wanvik edited comment on DERBY-4741 at 1/5/11 12:26 PM:
---------------------------------------------------------------
I find that explicit file sync (i.e. not "write sync") is only used if:
a) NIO is not supported (cf. WritableStorageFactory#supportsWriteSync), in which case we never use FileChannel#force
b) derby.storage.fileSyncTransactionLog is set to true
c) we are running on platforms/VMs that don't support opening a file with mask "rws" (write sync with metadata) and "rwd" (write sync without metadata), cf. check in LogToFile#openLogFileInWriteMode which calls checkJvmSyncError to determine this. The platforms mentioned are (e.g. early versions of 1.4.2 and 1.5 on Mac OS and FreeBSD).
If this holds, it seems to be we can just skip using the NIO version of RAF#sync for those platforms. Other platforms do not use the explicit file sync for the log, cf. the test in LogToFile#flush (snip):
if (isWriteSynced)
{
//LogAccessFile.flushDirtyBuffers() will allow only one write
//sync at a time, flush requests will get queued
logOut.flushDirtyBuffers();
}
else
{
if (!logNotSynced)
logOut.syncLogAccessFile();
}
On most platforms, isWriteSynced is true (cf above), meaning syncLogAccessFile is not used, so reverting to a interrupt safe, less performant non-NIO sync in syncLogAccessFile seems acceptable to me. Opinions?
was (Author: dagw):
I find that explicit file sync (i.e. not "write sync") is only used if:
a) NIO is not supported (cf. WritableStorageFactory#supportsWriteSync), in which case we never use FileChannel#force
b) derby.storage.fileSyncTransactionLog is set to true
c) On platforms/VMs that don't support opening a file with mask "rws" (write sync with metadata) and "rwd" (write sync without metadata), cf. check in LogToFile#openLogFileInWriteMode which calls checkJvmSyncError to determine this. The platforms mentioned are (e.g. early versions of 1.4.2 and 1.5 on Mac OS and FreeBSD).
If this holds, it seems to be we can just skip using the NIO version of RAF#sync for those platforms. Other platforms do not use the explicit file sync for the log, cf. the test in LogToFile#flush (snip):
if (isWriteSynced)
{
//LogAccessFile.flushDirtyBuffers() will allow only one write
//sync at a time, flush requests will get queued
logOut.flushDirtyBuffers();
}
else
{
if (!logNotSynced)
logOut.syncLogAccessFile();
}
On most platforms, isWriteSynced is true (cf above), meaning syncLogAccessFile is not used, so reverting to a interrupt safe, less performant non-NIO sync in syncLogAccessFile seems acceptable to me. Opinions?
> 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-a-04-api-interruptstatus.diff, derby-4741-a-04-api-interruptstatus.stat, derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat, derby-4741-b-01-nio.diff, derby-4741-b-01-nio.stat, derby-4741-b-02-nio.diff, derby-4741-b-02-nio.stat, derby-4741-b-03-nio.diff, derby-4741-b-03-nio.stat, derby-4741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff, derby-4741-c-01-nio.stat, derby-4741-kristians-01.diff, 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, InterruptResilienceTest.java, 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.