Enterprise Java Transactions Source: “Enterprise JavaBeans, 3rd Edition”, Richard Monson-Haefel

Enterprise Java v041130Transactions2 Transaction Definition Unit of work that accesses one or more shared resources (usually databases) –set of one or more activities related to each other –must be completed together or not at all –cohesion of unit is normally mission critical –examples ATM –withdraw from one source, deposit to another Order System –locate item, charge account, schedule shipment Medical System –identify medical state, dispense prescription

Enterprise Java v041130Transactions3 Transaction Properties Atomic –Transaction must execute completely or not at all Consistent –Data in database is always in a consistent state (makes sense) –constraints (primary keys, referential integrity, etc.) Isolated –Transaction executes without interference Durable –changes are not lost if the system crashes

Enterprise Java v041130Transactions4 EJB Transaction Support Declarative –transaction management controlled through deployment descriptor Programmatic –direct programming calls to Java Transaction Service (JTS) API –transaction management code mixed with business code –change in transactional behavior requires change in business code

Enterprise Java v041130Transactions5 Transaction Scope (one or more tasks that operate as a unit of work; succeed or be rolled back together) Tasks –EJB methods Unit of Work –Each bean visited by the methods during a thread of execution depending on bean transaction attributes –ends when thread of execution completes normally an exception is thrown transaction is rolled back

Enterprise Java v041130Transactions6 Transaction Attributes Supports Transactions –Required* –RequiresNew* –Mandatory* * Recommended for CMP 2.0 Entity Beans; support required Transactions not Supported @ support optional for CMP 2.0 Entity Beans

Enterprise Java v041130Transactions7 Setting the Declarative Transaction Attribute... Account * Supports

Enterprise Java v041130Transactions8 Container and Beans Pool Home EJBObject Home Interface Home Stub Remote Interface Remote Object Stub Account Bean Client Container create transfer

Enterprise Java v041130Transactions9 Not Supported Invoked EJB Client Thread of Execution Client’s Transaction Context No Transaction Context Transaction is suspended during the method of the Invoked EJB; resumes when method complete Transaction scope is not propagated to Invoked EJB or anything it invokes

Enterprise Java v041130Transactions10 Supports Invoked EJB Client Joins the transaction context if invoked as part of a transaction (A) Does not require a transaction; can be invoked outside of a transaction context (B) Thread of Execution Client’s Transaction Context No Transaction Context (A) (B)

Enterprise Java v041130Transactions11 Required Invoked EJB Client Joins the transaction context if invoked as part of a transaction (A) Initiates its own transaction context of invoked outside of a transaction (B) Thread of Execution Client’s Transaction Context No Transaction Context (A) (B) EJB’s Transaction Context

Enterprise Java v041130Transactions12 RequiresNew Invoked EJB Client Initiates its own transaction context whether called within am existing transaction context (A) or outside of a transaction context (B) Initiated transaction completes prior to returning to caller Thread of Execution Client’s Transaction Context No Transaction Context (A) (B) EJB’s Transaction Context

Enterprise Java v041130Transactions13 Mandatory Invoked EJB Client Joins the transaction context if invoked as part of a transaction (A) Throws a Transaction Exception if not called within a transaction context (B) (TransactionRequiredException for Remote Clients; TransactionRequiredLocalException for Local Clients) Thread of Execution Client’s Transaction Context No Transaction Context (A) (B) Transaction Exception

Enterprise Java v041130Transactions14 Never Invoked EJB Client Throws a Transaction Exception if called within a transaction context (A) (RemoteException to Remote Clients; EJBException to Local Clients) Must be invoked outside of a transaction context (B) Thread of Execution Client’s Transaction Context No Transaction Context (A) (B) Transaction Exception

Enterprise Java v041130Transactions15 Isolation and Database Locking What happens when two or more transactions attempt to access the same data –Dirty Reads first transaction reads uncommitted changes from a second transaction that may eventually be rolled back –Repeatable Reads data guaranteed to be the same if read multiple times during the same transaction; implemented with locks or snapshots –Phantom Reads first transaction sees new rows added by second transaction after beginning of the first transaction

Enterprise Java v041130Transactions16 Database Locks How do you prevent overlapping transactions from viewing the other’s data –Read Lock data is prevented from changing while transaction in progress –Write Lock prevents other transactions from modifying the data permits dirty reads by other transactions –Exclusive Write Lock prevents other transactions from reading and modifying data prevents dirty reads –Snapshots - frozen view of data

Enterprise Java v041130Transactions17 Transaction Isolation Levels Read Uncommitted can read data being modified by another transaction allows dirty, non-repeatable, and phantom reads Read Committed cannot read data being modified by another transaction allows non-repeatable and phantom reads; prevents dirty reads Repeatable Read cannot change data being read by another transaction allows phantom reads; prevents dirty and non-repeatable reads Serializable transactions can neither read or write same data

Enterprise Java v041130Transactions18 Specifying Isolation Level <!-- TRANSACTION_SERIALIZABLE TRANSACTION_READ_COMMITTED TRANSACTION_READ_UNCOMMITTED TRANSACTION_REPEATABLE_READ --> TRANSACTION_READ_COMMITTED Account *

Enterprise Java v041130Transactions19 Message Driven Bean Transactions Valid Values –Not Supported –Required Client transaction context not propagated to MDB –Supports, RequiresNew, Mandatory, and Never are relative to client

Enterprise Java v041130Transactions20 Exceptions within Transactions System Exceptions (ex. NullPointerException, EJBException) –container automatically rolls back transaction –bean instance is discarded ApplicationException (ex. AccountOverdrawException) –container does not automatically rollback transaction –exception delivered to client –client optionally signals rollback EJBContext.setRollbackOnly()

Enterprise Java v041130Transactions21 CMR and Transactions Collections obtained through CMR must be accessed within the same transaction public void processAccounts(CustomerLocal customer) { Collection accounts = customer.getAccounts(); for (Iterator i=accounts.iterator(); i.hasNext(); ) { } –processAccounts must have a transaction context active or will receive a java.lang.IllegalStateException when accessing accounts

Enterprise Java v041130Transactions22 Transaction/Bank Example Account –Entity Bean –Deployments (NotSupported, Supports, RequiresNew) –reports Application Exception (on overdraw) Teller –Stateless Session Bean –Deployments (Required) –calls EJBContext.setRollbackOnly() on exception TxClient/TxClientMain –instantiates Accounts with varying transaction support –uses Teller to perform actions on Accounts

Enterprise Java v041130Transactions23 AccountEJB public abstract class AccountEJB implements EntityBean { public void reset() { setBalance(0.0F); } public void deposit(float amount) throws AccountException { setBalance(getBalance() + amount); } public void withdraw(float amount) throws AccountException { float balance = getBalance(); if ((balance - amount) >= 0) { setBalance(balance - amount); } else { setBalance(balance - 1.0F); //subtract fee throw new AccountException("overdraw"); }...

Enterprise Java v041130Transactions24 TellerEJB public class TellerEJB implements SessionBean { public void transfer( AccountRemote fromAccount, AccountRemote toAccount, float amount) throws AccountException { try { toAccount.deposit(amount); fromAccount.withdraw(amount); } catch (AccountException ex) {ctx_.setRollbackOnly(); throw ex; } } public void reset(AccountRemote account) //similar to transfer … }

Enterprise Java v041130Transactions25 TxClient Initialization fromAccounts_ = new Hashtable(LAST_TYPE); toAccounts_ = new Hashtable(LAST_TYPE); for(int i=FIRST_TYPE; i<=LAST_TYPE; i++) { String id = uidGenerator_.createUID().toString(); AccountRemote account = createAccount(TX_TYPE[i], id); toAccounts_.put(TX_TYPE[i], account); id = uidGenerator_.createUID().toString(); account = createAccount(TX_TYPE[i], id); fromAccounts_.put(TX_TYPE[i], account); }

Enterprise Java v041130Transactions26 TxClient Transfer void transfer(int fromType, int toType) throws Exception { AccountRemote from =... AccountRemote to = … teller_.reset(from); teller_.reset(to); float amount = 5.00F; try { teller_.transfer(from, to, amount); } catch (AccountException ex) { System.out.print("transfer failed: " + ex); } finally { System.out.println(":from(" +from.getId()+ ")=" + from.getBalance() + ", to=(" +to.getId()+ ")=" + to.getBalance()); }

Enterprise Java v041130Transactions27 TxClient Execution private static void execute(final Context jndi) throws Exception { TxClient client = new TxClient(jndi); for(int i=FIRST_TYPE; i<=LAST_TYPE; i++) { for(int j=FIRST_TYPE; j<=LAST_TYPE; j++) { System.out.println(TX_TYPE[i] + "->" + TX_TYPE[j]); client.transfer(i,j); }

Enterprise Java v041130Transactions28 Running the Example Deploy the EJB/EAR –$ coredev txBankApp init Run the Client –$ coredev txBankApp

Enterprise Java v041130Transactions29 TxClient Output NotSupported->NotSupported transfer failed: overdraw:from(19197 )=-1.0, to=(19196 )=5.0 NotSupported->Supports transfer failed: overdraw:from(19197 )=-1.0, to=(19198 )=0.0 NotSupported->RequiresNew transfer failed: overdraw:from(19197 )=-1.0, to=(19200 )=5.0 Supports->NotSupported transfer failed: overdraw:from(19199 )=0.0, to=(19196 )=5.0 Supports->Supports transfer failed: overdraw:from(19199 )=0.0, to=(19198 )=0.0 Supports->RequiresNew transfer failed: overdraw:from(19199 )=0.0, to=(19200 )=5.0

Enterprise Java v041130Transactions30 TxClient Output RequiresNew->NotSupported transfer failed: overdraw:from(19201 )=-1.0, to=(19196 )=5.0 RequiresNew->Supports transfer failed: overdraw:from(19201 )=-1.0, to=(19198 )=0.0 RequiresNew->RequiresNew transfer failed: overdraw:from(19201 )=-1.0, to=(19200 )=5.0 DEFAULT->DEFAULT transfer failed: overdraw:from(19203 )=0.0, to=(19202 )=0.0

Enterprise Java v041130Transactions31 Managing the transfer() Transaction Context to:AccountEJB from:AccountEJB TellerEJB Transaction Manager TxClient 1: transfer() 2: register TellerEJB Supports Required Transaction Context TellerEJB to:AccountEJB from:AccountEJB 3: create tx context; add TellerEJB 4: deposit 5: register to:AccountEJB 6: add to:AccountEJB 7: withdraw 8: register from:AccountEJB 9: add from:AccountEJB 10: verify all will work 11: commit or rollback all updates

Enterprise Java v041130Transactions32 Distributed Tx Architecture Two Phase Commit (2-PC/TPC) Transaction Coordinator TX Manager TX Manager Resource Manager Resource Manager 1. Prepare to Commit 2. Return 3. Log Result 4. commit 5. return

Enterprise Java v041130Transactions33 Resource Managers Examples –JDBC Drivers –JMS Provider

Enterprise Java v041130Transactions34 Adding Another Resource Manager (JMS) to Teller public void transfer( AccountRemote fromAccount, AccountRemote toAccount, float amount) throws AccountException { try { msg_.setString("type", "transfer"); //... publisher_.publish(msg_); toAccount.deposit(amount); fromAccount.withdraw(amount); } catch (AccountException ex) { ctx_.setRollbackOnly(); throw ex; } //... } //reset() is similar to transfer

Enterprise Java v041130Transactions35 Checking commited Results in TxClient try { teller_.reset(from); teller_.reset(to); } finally { if (subscriber_.receive(1000 * 1) == null) { System.out.println("didn't get first reset message"); } if (subscriber_.receive(1000 * 1) == null) { System.out.println("didn't get second reset message"); }

Enterprise Java v041130Transactions36 Checking rollback Results in TxClient try { teller_.transfer(from, to, amount); } catch (AccountException ex) { System.out.print("transfer failed: " + ex.getMessage()); } finally { System.out.print(":from(" +from.getId()+ ")=" + from.getBalance() + ", to=(" +to.getId()+ ")=" + to.getBalance()); if (subscriber_.receive(1000 * 1) == null) { System.out.println(":no message"); }

Enterprise Java v041130Transactions37 TxClient Output with Two Resource Managers //note that resets received expected messages NotSupported->NotSupported transfer failed: overdraw:from(19205 )=-1.0, to=(19204 )=5.0:no message NotSupported->Supports transfer failed: overdraw:from(19205 )=-1.0, to=(19206 )=0.0:no message NotSupported->RequiresNew transfer failed: overdraw:from(19205 )=-1.0, to=(19208 )=5.0:no message Supports->NotSupported transfer failed: overdraw:from(19207 )=0.0, to=(19204 )=5.0:no message Supports->Supports transfer failed: overdraw:from(19207 )=0.0, to=(19206 )=0.0:no message Supports->RequiresNew transfer failed: overdraw:from(19207 )=0.0, to=(19208 )=5.0:no message

Enterprise Java v041130Transactions38 TxClient Output with Two Resource Managers RequiresNew->NotSupported transfer failed: overdraw:from(19209 )=-1.0, to=(19204 )=5.0:no message RequiresNew->Supports transfer failed: overdraw:from(19209 )=-1.0, to=(19206 )=0.0:no message RequiresNew->RequiresNew transfer failed: overdraw:from(19209 )=-1.0, to=(19208 )=5.0:no message //extra output DEFAULT->DEFAULT transfer failed: overdraw:from(19211 )=0.0, to=(19210 )=0.0:no message

Enterprise Java v041130Transactions39 Enable 2PC Transactions for Connection Pool

Enterprise Java v041130Transactions40 Enable JTS Transactions in Entity Bean Account corej2ee.jdbc.corej2eeTxDS txbank_Account

Enterprise Java v041130Transactions41 Enable JTS Transactions for JMS

Enterprise Java v041130Transactions42 Bean Types and Transactions Entity –In EJB 1.1 must be container managed –may force a rollback with setRollbackOnly() Stateless Session –transactions simple. Abort by throwing EJBException Stateful Session –What about the conversational state ? –Have to respond to transaction aborts to keep conversational state consistent

Enterprise Java v041130Transactions43 Stateful Session Bean and Transactions (Cont) Can implement Session Synchronization interface –afterBegin(), beforeCompletion(), afterCompletion(boolean) If afterCompletion is false, you can roll back the conversational state SessionSynchronization can not be implemented with bean-managed tx

Enterprise Java v041130Transactions44 SessionSynchronization Example public class SessionSynchronizedTellerEJB implements SessionBean, javax.ejb.SessionSynchronization { public void reset(AccountRemote account) throws AccountException {... public void transfer( AccountRemote fromAccount, AccountRemote toAccount, float amount) throws AccountException {... public void afterBegin() {} public void beforeCompletion() {} public void afterCompletion(boolean committed) { } … }

Enterprise Java v041130Transactions45 Programmatic Transactions Bean programmer is responsible for issuing begin(), commit(), and abort() calls in code Discouraged - Why not let the container do it ? Use Java Transaction API (JTA) –Simple layer over Java Transaction Service (JTS) which is an implementation of the CORBA Object Transaction Service (OTS)

Enterprise Java v041130Transactions46 User Transaction Required EJB Transaction interface Provides access to transaction service –can start and commit –can mark that transaction must be rolled back Client and server components can use Container/Server does not have to expose JTS API to the bean

Enterprise Java v041130Transactions47 User Transaction

Enterprise Java v041130Transactions48 Code Example public void transfer(AccountRemote from, AccountRemote to, float amount ) throws AccountException { UserTransaction tx = null; try { tx = ctx_.getUserTransaction(); tx.begin(); // perform JDBC operations and transfer the money tx.commit(); } catch (Exception ex) { tx.setRollbackOnly(); throw new AccountException(); }

Enterprise Java v041130Transactions49 Programmatic Transactions in EJB Allowed in Session Beans... Bean –Stateless Session Beans must begin/end in same method –Stateful Session Beans may begin/end in separate methods (although not advised) EJB 1.1 disallows this for Entity Beans Bean controls transactions programmatically

Enterprise Java v041130Transactions50 Transactional Clients End user can also control transactions UserTransaction ut = (UserTransaction) jndiContext.lookup(“javax.transaction.UserTransaction”); ut.begin(); // perform multiple operations on beans account1.deposit( 34 ); account2.withdraw( 34 ); ut.commit();

Enterprise Java v041130Transactions51 Client Issues Lots of network traffic required when client manages transactions More complicated Should have asked a session bean to perform the set of operations over on the server Transactions should be short

Enterprise Java v041130Transactions52 Performance Implications Avoid distributed transactions across multiple resource managers and/or multiple transaction managers –Consider JMS synchronization Avoid client control of transaction boundaries –Try to encapsulate transactional business operations in session beans

Enterprise Java v041130Transactions53 EJB Transaction Summary Supports EJB goal of removing middleware programming burden from bean programmer Declare transactional requirements in deployment descriptor Transactions have performance implications –limit client control, distributed transactions –can control frequency of ejbLoad and ejbStore