[jira] [Commented] (JENA-324) An exception thrown from commit() leaves the StoreConnection in an inconsistent state.

["Mark Buquor (JIRA)" <ji...@apache.org>]

    [ 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