6

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?

Sizons
  • 640
  • 2
  • 8
  • 24
Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911

1 Answers1

8

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.

Ludovic Orban
  • 396
  • 1
  • 6
  • 1
    Thanks for your response Ludovic. The thing is we are about to release our system into production and we haven't had the time to test it with the "after_transaction" flag set. Due to the complexity of Spring TM, Hibernate Transaction Logic wrapper and Bitronix inner workings, it's very difficult to pin point the culprit. Although I've seen the 2 connection enlisted the 2PC will simply treat them as just 2 isolated XAResources, so the TX atomicity is guaranteed. Maybe after the production launch, I'll have more time to dig into it. – Vlad Mihalcea May 22 '14 at 07:58
  • When I chase this kind of problem, BTM debug logs are invaluable. Enable them and make sure that you configure Mapped Diagnostic Context to display the GTRID (see http://docs.codehaus.org/display/BTM/DebugLogging2x). This way, you can easily separate work done on behalf of each transaction (e.g. by splitting the logs per transaction with a simple grep) and fairly easily follow the connection pool's logic flow. – Ludovic Orban May 22 '14 at 08:03
  • 1
    Thanks, I'll definitely try it. It's quite frustrating that we couldn't ever isolate the issue in a unit or integration test. I have a system integration test, running against an actual production-like server where I could see this anomaly reported in logs. When I collect the info, I'll obfuscate some class names and post them to the BTM issue post,, maybe you can spot some flow anomaly. – Vlad Mihalcea May 22 '14 at 08:13