Is it safe to set Hibernate after_transaction as a JTA connection release mode when using Bitronix Transcation Manager?

Question

According to Hibernate docs, in a JTA environment the default connection release mode is after_statement, meaning that after each statement the hibernate logical connection is released.

When the logical connection is released, the Connection close() method is called and the current resource is de-listed from the transaction manager.

According to RedHat transaction developer guide:

"The delistResource method is used to dissociate the specified resource from the transaction context in the target object. The application server invokes the method with two parameters:

An XAResources object, which represents the resource.
A flag to indicate whether the operation is due to the transaction being suspended (TMSUSPEND), a portion of the work has failed (TMFAIL), or a normal resource release by the application (TMSUCCESS)."

Since Bitronix uses TMSUCCESS:

 currentTransaction.delistResource(xaResourceHolderState.getXAResource(), XAResource.TMSUCCESS);

It means the connection is disassociated from the current transaction branch and sometimes you may end up enlisting 2 different connections for the same Resource Adapter.

I think that holding the connection for as much as the Transaction is taking place is a better choice, since we usually execute more than one statement per transaction. So the after_transaction release mode sounds more appealing.

Is the after_transaction release mode more appropriate with Bitronix? Has anyone experienced it in a production environment?

Answer 1

You should not see any difference between after_statement and after_transaction, at least with BTM. In theory, after_statement is "more correct" as the connection and transaction are supposed to be completely independent in a XA context and a connection is supposed to be able to serve multiple transactions at once. In practice, connections and transactions almost never are independent as almost no resource supports this.

The BTM connection pool implements a relatively complex FSM that allows it to keep the transactions isolated on their connection while at the same time re-using a connection when possible.

Within the context of a single transaction, repeatedly acquiring a connection from the pool then closing it should only consume a single connection from the pool: the very same one should always be set aside by the pool and re-used. The only reason I can think of that would result in two connections being consumed from the pool is if you acquire a connection again while the first one hasn't been closed yet. Any other reason can probably be considered a bug in BTM's connection pool.