Distributed Transactions in Java EE Nikolai Tankov SAP Labs Bulgaria January 19th, 2008 Sofia, Bulgaria.

Distributed Transactions inJava EE

Nikolai TankovSAP Labs Bulgaria January 19th, 2008

Sofia, Bulgaria

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

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.

Conceptual View of DTP model

TransactionManager

Application Server or Application program

javax.transaction.TransactionManager

javax.transaction.UserTransaction

javax.transaction.TransactionSynchronizationRegistry

ResourceManager1

Message Broker

ResourceManager2

DB

javax.transaction.xa.*

javax.transaction.xa.*

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.

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.

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.

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.

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>

2 phase commit sequence

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.

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

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.

Possible DTP optimizations

Last agent optimization (Last resource optimization)

Read only optimization One phase commit optimization Local transaction optimization

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

Read only optimization

Resource managers which were used only for read operations are not involved into second commit phase

One phase commit optimization

Used when only one XAResource is enlisted into transaction. XAResource.prepare() call is skipped.

Local transaction optimization Local transactions are used if only one resource manager will participate

into distributed transaction.

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

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();}

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

Thank You! Nikolai Tankov

[email protected]

Additional slides

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.

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.

Tx standards – WS – Business Activity

■ A coordinator for an AtomicOutcome coordination type must direct all participants to close or all participants to compensate.

Tx standards – WS – Business Activity

■ A coordinator for a MixedOutcome coordination type may direct each individual participant to close or compensate.