Distributed Transactions in Java EE

1. Distributed Transactions inJava EE Nikolai Tankov SAP Labs Bulgaria January 19th, 2008Sofia, Bulgaria

2. Agenda • APIs for transaction management in Java EE • How TransactionManager works • Distributed transactions optimizations • Example of 2PC • Demo of 2PC and automatic recovery • 2 PC issues in some DB-s

3. Transaction types • Local transaction - A transaction that involves only one resource manager (e. g. accesses only one database). Support all the ACID properties (atomicity, consistency, isolation and durability) • Distributed transaction - accesses and updates data on two or more networked resources (e. g. RDBMSs). Support all the ACID properties. • Short-living transaction – support all the ACID properties. • Long-living transaction – do not support ACID properties.

4. Conceptual View of DTP model Transaction Manager Application Server or Application program javax.transaction.TransactionManager javax.transaction.UserTransaction javax.transaction.TransactionSynchronizationRegistry ResourceManager1 javax.transaction.xa.* ResourceManager2 javax.transaction.xa.* DB Message Broker

5. JTA API is modeled on the X/Open XA standard • javax.transaction.TransactionManager – used by the application server itself to control transactions. • javax.transaction.UserTransaction – provides the application the ability to control transaction boundaries programmatically. • Javax.transaction.TransactionSynchronizationRegistry – introduced in JSR 907. Used from frameworks for association of arbitrary objects with transactions.

6. javax.transaction.xa.XAResource. • start(xid, flags) - Starts work on behalf of a transaction branch specified in xid. • end(xid, flags) - Ends the work performed on behalf of a transaction branch. • prepare(xid) - Ask the resource manager to prepare the transaction specified in xid for commit. • recover – obtain a list of prepared transaction branches which were not commited or rolledback • commit(xid, boolean onePhase)- Informs the resource manager to commits the global transaction specified by xid. • rollback(xid) – Informs the resource manager to rollbacks the global transaction specified by xid.

7. javax.transaction.xa.XID interface XID = key for one transaction branch. XID contains: • Format ID – int. Must be >0, usually format id is 0 • Global transaction id - ID of the distributed transaction. This is byte[] with length up to 64 bytes. • Branch Qualifier –ID of the transaction branch. This is byte[] with length up to 64 bytes. Global transaction Id and branch qualifier taken together must be globally unique.

8. How TransactionManager works • Transactions are associated with threads. • Transaction objects are invisible for applications. • Application server is responsible to obtain XAResource from each resource manager that was used during transaction and enlist it into transaction • There is no problem to have stacked transactions. • Nested transactions usually are not supported.

9. How to start distributed transaction • Programmatically UserTransaction ut = (new InitialContext()).lookup(“java:comp/UserTransaction”); ut.begin(); … ut.commit() • Declaratively • @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public Foo bar() { • In ejb-jar.xml <trans-attribute>Required </trans-attribute>

10. 2 phase commit sequence

11. In-Doubt transactions Transaction becomes in-doubt when one or more RM-s failed to commit due to a system or network error? • Reasons for in-doubt transactions • Network failure • DB crash • TransactionManager crush • Resolution of in-doubt transactions • Automatic – TransactionManager checks periodically for in-doubt transactions and resolves them • Manually resolve transactions with DB specific tools.

12. Heuristics • XA_HEURHAZ - the transaction branch may have been heuristically completed • XA_HEURMIX - the transaction branch has been heuristically committed and rolled back. • XA_HEURCOM - the transaction branch has been heuristically committed • XA_HEURRB - the transaction branch has been heuristically rolled back

13. Requirements for resource managers • Keep information about each transaction which is not completed • Must be able ensure that commit is possible. • If RM votes for commit it must store this promise into durable storage. • Implement recover function by listing RM Tlog for in-doubt transactions. • Ensure that HeuristicHazard and HeuristicMixed will not happened. • Minimize heuristic decisions.

14. Possible DTP optimizations • Last agent optimization (Last resource optimization) • Read only optimization • One phase commit optimization • Local transaction optimization

15. Last agent optimization • It is possible to enlist 0 or 1 resources with Local transaction(LT) support • All prepare methods are invoked and after that commit of the LT resource

16. Read only optimization • Resource managers which were used only for read operations are not involved into second commit phase

17. One phase commit optimization • Used when only one XAResource is enlisted into transaction. • XAResource.prepare() call is skipped.

18. Local transaction optimization • Local transactions are used if only one resource manager will participate into distributed transaction.

19. Inbound transaction model • Introduced in Java Connector 1.5 • Allows a EIS to propagate transaction context to an application server • Allows a resource adapter to commit, rollback and recover the transaction branch. • Application server is RM for external system

20. Example uses the 2PC protocol to commit onetransaction branch xaConnection = xaDataSource.getXAConnection("user", "password"); xaResource = xaConnection.getXAResource(); connection = xaConnection.getConnection(); stmt = connection.createStatement(); int ret; xid = new MyXid(100, new byte[]{0x01}, new byte[]{0x02}); try { xaResource.start(xid, XAResource.TMNOFLAGS);// be careful with other flags stmt.executeUpdate("insert into test_table values (100)"); xaResource.end(xid, XAResource.TMSUCCESS); try { ret = xaResource.prepare(xid); } catch (XAException e) { // prepare failed, most of the error codes are returned via XAException xaResource.rollback(xid); } if (ret == XAResource.XA_OK) { xaResource.commit(xid, false); } else if(ret != XAResource.XA_RDONLY ){ xaResource.rollback(xid); } } catch (XAException e) { e.printStackTrace(); } finally { stmt.close(); connection.close(); xaConnection.close(); }

22. Problems with different DB-s • Commit from arbitrary XAResource is not working. • XAResource instance is closed before close of XAConnection. This problem is valid for all DB2X drivers and does not exist in Oracle, SQL server and MaxDB. • It is not possible to have 2 and more connections from one RM that are working in parallel on one transaction. If one connection is started it is not possible to start another connection with same transactionID • With default configuration recover is not working on Oracle. • All Oracle releases before 9.2.0.5 are not stable. Oracle 8 does not support 2PC with default configuration. • Sometimes recover does not return all xids of in-doubt transactions

23. Thank You! Nikolai Tankovnikolai.tankov@sap.com

24. Additional slides

25. Tx standards – WS Coordination • This specification describes a framework for a coordination service (or coordinator) which consists of the following component services: • An Activation service with an operation that enables an application to create a coordination instance or context. • A Registration service with an operation that enables an application to register for coordination protocols. • A coordination type-specific set of coordination protocols.

26. Tx standards – WS - Atomic Transaction This specification defines the following protocols for atomic transactions: • Completion protocol: initiates commitment processing. Based on each protocol's registered participants, the coordinator begins with Volatile 2PC then proceeds through Durable 2PC. • Two-Phase Commit (2PC): The 2PC protocol coordinates registered participants to reach a commit or abort decision, and ensures that all participants are informed of the final result. The 2PC protocol has two variants: • Volatile 2PC: Participants managing volatile resources such as a cache should register for this protocol. • Durable 2PC: Participants managing durable resources such as a database should register for this protocol. • A participant can register for more than one of these protocols by sending multiple Register messages.

27. Tx standards – WS – Business Activity • A coordinator for an AtomicOutcome coordination type must direct all participants to close or all participants to compensate.

28. Tx standards – WS – Business Activity • A coordinator for a MixedOutcome coordination type may direct each individual participant to close or compensate.