1. Distributed Transactions in Java EE Nikolai Tankov SAP Labs Bulgaria January 19th, 2008 Sofia, 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.TransactionSynchroni zationRegistry ResourceManager1 Message Broker ResourceManager2 DB javax.transaction.xa.*

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 Required

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 one transaction 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 Tankov nikolai.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.