EAServer supports dynamic enlistment for bean-managed transactions, which allows you to create a connection in one method of a stateful bean, use the connection in another method, and close the connection in a third method.
For a JDBC 2.0 shared connection (PooledConnection), the container manages the single connection’s enlistment and deenlistment in transactions.
For XA connections, the Object Transaction Service libraries need to know all the resources that will participate in a transaction when it starts. If you get an XAConnection before you start a transaction, EAServer enlists the XAConnection in the transaction. If you start a transaction before you create an XAConnection, EAServer creates the connection and enlists it in the transaction.
Dynamic enlistment allows you to do this:
conn1 = ds1.getConnection(); // A user_transaction.begin(); // conn2 = ds2.getConnection(); conn3 = ds3.getConnection(); // B conn2.close(); // user_transaction.commit(); // C conn3.close(); conn1.close();
Where at these points, the following are true:
A – conn1 is not part of any transaction.
B – conn1, conn2, and conn3 are part of the user_transaction.
C – conn1 and conn3 are not part of any transaction.
Earlier versions of EAServer required you to get and release connections within a single component method. In bean-managed transactions, you had to get and release a connection within the scope of a transaction.
You can get only one connection per resource. Each getConnection call for the same database returns the same connection.
XA performance diminishes when connections span across
methods.
