Atomikos Forum

Transactions never call prepare()

I'm sure this is a case of new-user syndrome, but I've pounded my head on this for hours and I'm not spotting the solution.

I'm using AtomikosDataSourceBean with a Postgres PGXADataSource to supply XA connections.  The database has been properly configured to enable prepared transactions, which I've verified both via psql and via some test Java code using PGXADataSource directly.  But I'm damned if I can come up with a simple test using Atomikos that would do the same.  I can make SQL operations work, that's not a problem, they just aren't XA transactions.  I tracked down the prepare() methods in the Atomikos source and stepped through in debug mode to verify I never get into any kind of state that would invoke them.

Simplifying the code, what I'm doing is:

PGXADataSource pds = new PGXADataSource();
// then init pds properties to specify database conn

AtomikosDataSourceBean adsb = new AtomikosDataSourceBean();
adsb.setUniqueResourceName("foobar");
adsb.setXaDataSource(pds)
// then init adsb properties to specify pool handling

TransactionManager tm = new UserTransactionManager();
tm.begin();

Connection conn = adsb.getConnection();
conn.setAutoCommit(false);
Statement stmt = conn.createStatement();
stmt.executeUpdate("insert ...");

conn.close();
tm.commit();


Now, the AtomikosDataSourceBean says it automatically registers with the transaction service and takes part in all active transactions, but I can find where the handoff is between that bean, the transaction manager, the data source, or the SQL operations, that would ever cause a prepare() to be called.  Note that I've tried a few variations on the code above, nothing seems work, and I have yet to trip over the code path that would.

I'm using a Postgres 9.3 db, the 9.3 JDBC jar, and Atomikos 3.9.3.

Any assistance to the new user would be greatly appreciated.
Reid Pinchback Send private email
Wednesday, February 25, 2015
 
 
That should have said "but I can't find where the handoff is..."
Reid Pinchback Send private email
Wednesday, February 25, 2015
 
 
I finally found out the solution.

Atomikos notices how many participants there are in a transaction.  It only causes a prepare if there are 2 or more participants.  The relevant code is in the CoordinatorImp.terminate method.
Reid Pinchback Send private email
Wednesday, February 25, 2015
 
 
Hi,

Correct. If you only use one resource then we resort to 1-phase commit - an optimisation to avoid the prepare() overhead.

Apologies for the delay; we monitor our email support all day so the forums tend to lag behind if there are too many email (support) requests.

Best
Guy Pardon Send private email
Monday, March 02, 2015
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics