[
https://issues.apache.org/jira/browse/JENA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457141#comment-13457141
]
Mark Buquor commented on JENA-324:
----------------------------------
Just a note on severity. This is not a critical issue for me if I can safely
recover from these situations. For my needs, I can treat any exception from
commit() as an abort and retry the operation later. With the example
IOException in 0.9.1, the journal was corrupt and the implications were more
serious. With 0.9.4 enhancements, the corrupt journal appears to be
recoverable. StoreConnection.expel(location, true) looks like it will clear the
stuck transaction and trigger journal recovery without restarting, but I'd like
to get this blessed as a workaround due to its "testing only" status.
> An exception thrown from commit() leaves the StoreConnection in an
> inconsistent state.
> --------------------------------------------------------------------------------------
>
> Key: JENA-324
> URL: https://issues.apache.org/jira/browse/JENA-324
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
> Affects Versions: TDB 0.9.1, TDB 0.9.2, TDB 0.9.3, TDB 0.9.4
> Reporter: Mark Buquor
>
> An exception thrown from commit() leaves the StoreConnection in an
> inconsistent state.
> Example: After a commit() throws an IOException in prepare() due to
> insufficient disk space, I see the following behavior:
> dataset.isInTransaction() == false
> dataset.abort() throws TDBTransactionException: "Transaction has already
> committed or aborted"
> dataset.end() appears OK
> dataset.begin(ReadWrite.READ) appears OK
> dataset.begin(ReadWrite.WRITE) blocks on writersWaiting.acquire()
>
> The debugger shows that the transaction is stuck in limbo: active, closed,
> and unfinished.
> TransactionManager.activeWriters: 1
> TransactionManager.activeTransactions: 1
> [Transaction: 151 : Mode=WRITE : State=CLOSED : X:\RELM1\]
> changesPending=true
> outcome=UNFINISHED
> Short of a fix, it looks like the only option to clear the stuck transaction
> is StoreConnection.expel(location, true), which has the comment "testing
> only".
> There's also the indeterminacy of ending a transaction that, as far as I can
> tell at the Dataset level, may or may not be committed ("Transaction has
> already committed or aborted").
> Rough outline of a commit:
> state == TxnState.PREPARING
> -- commitPrepare()
> -- journal.write()
> -- journal.sync() // Commit point.
> state == TxnState.COMMITED
> -- noteTxnCommit()
> -- currentReaderView.set(null)
> -- writersWaiting.release()
> noteTxnCommit() is called after the commit and performs IO, so it appears
> that if commit() throws an exception, it's not necessarily true that the
> transaction is effectively aborted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
