Bug in state handling in Txn.

Encountered a potential bug with how a failed txn.commit is handled.

Test case: https://github.com/dzajkowski/lmdbjava/blob/e0d6b6c545970847f6288d84421a919150278397/src/test/java/org/lmdbjava/TxnTest.java#L265

Results in:

Unexpected exception, expected<org.lmdbjava.Env$MapFullException> but was<org.lmdbjava.Txn$NotReadyException>

it boils down to (TXN:107):

    state = DONE;
    checkRc(LIB.mdb_txn_commit(ptr));

first setting the state to DONE and then committing a txn which can throw e.g. MapFullException.

Shouldn’t the lines be switched? Or is the try ... catch pattern misused here?

[benalexau]

I’ve had a good look at this issue today and I am of the view the current handling is correct.

I was able to run your test case and reproduce the failure. However the code is calling Txn.commit(), catching the raised MapFullException, and then unnecessarily invoking Txn.abort() on what is by then an invalid transaction. The MapFullException was raised when you called Txn.commit(). The subsequent invocation of Txn.abort() raises NotReadyException because the transaction is no longer valid and the more meaningful exception had already been returned to user code earlier.

By way of background, the LMDB C mdb_txn_commit documentation states, “The transaction handle is freed”. So this happens irrespective of the return code from mdb_txn_commit. If one attempts to then call mdb_txn_abort for the same transaction handle, the C library will crash. To illustrate inverting the Txn.java:107 statement your test case crashes the JVM with “The forked VM terminated without properly saying goodbye. VM crash or System.exit called?”.

LmdbJava protects you from a segmentation fault by raising the NotReadyException when an attempt is made to use a transaction that can no longer be aborted (as in this case). The correct method to call (and what will be called if Txn was created in the initialization of a try-with-resources block) is Txn.close(). The Txn.close() method will not raise any LMDB-related exception.

I hope this clarifies things. In a nutshell, don’t commit then abort. Just commit or abort, then close.

[dzajkowski]

Thanks for the clarification.