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.TransactionSynchronizationRegist
ry
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.TransactionSynchronizationRegist
  ry 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 gt0, 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()).lo
  okup(javacomp/UserTransaction)
• ut.begin()
• ut.commit()
• Declaratively
• _at_TransactionAttribute(TransactionAttributeType.RE
  QUIRES_NEW)
• public Foo bar()
• In ejb-jar.xml
• lttrans-attributegtRequired lt/trans-attributegt

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("use
r", "password") xaResource xaConnection.getXARe
source() connection xaConnection.getConnection(
) stmt connection.createStatement() int
ret xid new MyXid(100, new byte0x01, new
byte0x02) 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()
21
(No Transcript)
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_at_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.