1. Java Transactions Service Presented by: Dina Sarhan Rana El Hattab

2. The Java Transaction Service  The Java Transaction Service is a key element of the J2EE architecture. Together with the Java Transaction API, it enables us to build distributed applications that are robust to all sorts of system and network failures.  If you look at any source on J2EE, you'll find that only a small part of the material discusses the both Java Transaction Service (JTS) and the Java Transaction API (JTA). This does not undermine the importance of JTS as JTS gets less press than EJB technology because the services it provides to the application are largely transparent many developers are not even aware of where transactions begin and end in their application.

3. What is a Transaction?  What is an application's state?  A transaction can be defined as a related collection of operations on the application state.  In other words, a transaction is a unit of work done by multiple distributed components on shared data.  A transaction has certain properties that are collectively referred to as ACID properties.

4. ACID Properties of Transaction  Atomicity-all changes that a transaction makes to a database are made permanent; otherwise, all changes are rolled back.  Consistency-a successful transaction transforms a database from a previous valid state to a new valid state.  Isolation-changes that a transaction makes to a database are not visible to other operations until the transaction completes its work.  Durability-changes that a transaction makes to a database survive future system or media failures.

5. Uses of Transactions  Java Transactions is one of the most crucial requirements for enterprise application development in the domains of finance, banking and electronic commerce.  Online Document Processing  Regional Inventory Management Systems  In general, any application that involves sharing data among multiple distributed components.

6. Older Transaction Technologies  X/Open Distributed Transaction Processing Model

7.  Application Programs : implement transactional operations.  Resource Managers  Transaction Managers  Communication Resource Manager which facilitate interoperability between the different transaction managers in different transaction processing domains.

8. Some of the Interfaces implemented  TX Interface  XA Interface :This interface is used to support global transactions across different transaction manager domains via communication resource managers.  TXRPC Interface :interface provides portability for communication between application programs within a global transaction.

9. OMG Object Transaction Service  The OTS model is based on the X/Open DTP model with the following enhancements:  The OTS model replaces the functional XA and TX interfaces with CORBA IDL interfaces.IDL  The OTS is interoperable with X/Open DTP model.

10. OMG Object Transaction Service  Transaction Client  Transactional Object:A CORBA object that encapsulates or refers to persistent data, and whose behavior depends on whether or not its operations are invoked during a transaction.  Recoverable Object:A transactional object that directly maintains persistent data, and participates in transaction protocols  Transactional Server  Recoverable Server  Resource Object

11. Additional features of the CORBA OTS  Nested Transactions: This allows an application to create a transaction that is embedded in an existing transaction. In this model, multiple subtransactions can be embedded recursively in a transaction.  The main advantage of this model is that the application will have an opportunity to correct or compensate for failures at the subtransaction level, without actually attempting to commit the complete parent transaction.

12.  Application Synchronization: Using the OTS synchronization protocol, certain objects can be registered with the transaction service for notification before the start of and the completion of the two-phase commit process. This enables such application objects to synchronize transient state and data stored in persistent storage.two-phase commit

13. Java Transaction Initiative - Architecture  The Java transaction initiative consists of two specifications: Java Transaction Service (JTS) and Java Transaction API (JTA).  JTS specifies the implementation of a Java transaction manager.  The JTA specifies an architecture for building transactional application servers and defines a set of interfaces for various components of this architecture.

14. Java Transaction Initiative - Architecture JTA JTS Application Server Resource manager

15. Java Transaction Service (JTS) architecture:  The Java Transaction Service is architected around an application server and a transaction manager as shown in the next slide and consists of:  Transaction Manager: The transaction manager is the core component of this architecture and is provided by an implementation of the JTS.  Application Server: The application server abstracts all transactional semantics from the application programs.

16. Java Transaction Service (JTS) architecture:  Application Components: These are the clients for the transactional resources that implement business transactions and are deployed on the application server. Depending on the architecture of the application server, these components can directly or indirectly create transactions and operate on the transactional resources.  Resource Manager: A resource manager is an X/Open XA compliant component that manages a persistent and stable storage system.  Communication Resource Manager: allows the transaction manager to participate in transactions initiated by other transaction managers.

17. Java Transaction Service (JTS) architecture:

18. Some Useful Examples:  If: The client application needs to make invocations on several objects, which may involve write operations to one or more databases. The client application needs a conversation with an object managed by the server application, and the client application needs to make multiple invocations on a specific object instance. Within the scope of a single client invocation on an object, the object performs multiple edits to data in a database. If one of the edits fails, the object needs a mechanism to roll back all the edits.

19. Java Transaction API (JTA)

20. Packages : javax.transactionjavax.transaction  Provides the API that defines the contract between the transaction manager and the various parties involved in a distributed transaction ex : resource manager, application, and application server.  The UserTransaction interface can always be used in the following components:  Web components (JSPs and Servlets)  Session beans with bean-managed transactions enabled.

21. Interfaces implemented in javax.transaction  StatusThe Status interface defines static variables used for transaction status codes. Status  SynchronizationThe transaction manager provides a synchronization mechanism that allows involved parties to be notified before and after a transaction completes. Synchronization  TransactionThe Transaction interface allows operations to be performed against the transaction in the target Transaction object. Transaction  TransactionManagerThe TransactionManager interface defines the methods that allow an application server to manage transaction boundaries. TransactionManager  UserTransactionThe UserTransaction interface defines the methods that allow an application to explicitly manage transaction boundaries. UserTransaction

22. Packages cont’d  javax.transaction.xaProvides the API that defines the contract between the transaction manager and the resource manager, which allows the transaction manager to enlist and delist resource objects in JTA transactions. javax.transaction.xa

23. Interfaces in javax.transaction.xa  XAResourceThe XA Resource interface is a Java mapping of the industry standard XA interface based on the X/Open CAE Specification XAResource  XidThe Xid interface is a Java mapping of the X/Open transaction identifier XID structure. Xid

24.  XAExceptionThe XAException is thrown by the Resource Manager (RM) to inform the Transaction Manager of an error encountered by the involved transaction. XAException

25. Transaction Functions  begin() - Create a new transaction  commit() - Complete the current thread's transaction  rollback() - Abort the current thread's transaction  setRollbackOnly() - Ensure that the transaction must rollback

26. Code Sample  import javax.naming.*;  import javax.transaction.*;  import javax.sql.*;  import javax.ejb.*;  import javax.jms.*; import java.sql.*;

27. // This code fragment sits Inside a session bean. // The instance variable ctx represents a SessionContext. UserTransaction ut =ctx.getUserTransaction(); ut.begin();

28. // Each of these environment entries is arbitrarily named and would be set in the EJB's // deployment descriptor, and set up in the J2EE server's administration tool. DataSource ds1 = (DataSource) ic.lookup("java:comp/env/jdbc/DatabaseOne"); DataSource ds2 = (DataSource) ic.lookup("java:comp/env/jdbc/DatabaseTwo"); QueueConnectionFactory qcf = (QueueConnectionFactory) ic.lookup("java:comp/env/jms/JMSQ");

29. try { // perform work with the three resources ut.commit(); } catch (Exception e) { ut.rollback(); } finally { // close resources }

30. References:  http://www.subrahmanyam.com/artic les/jts/JTS.html http://www.subrahmanyam.com/artic les/jts/JTS.html  http://edocs.beasys.com/wls/docs60/ jta/gstrx.html#1018509 http://edocs.beasys.com/wls/docs60/ jta/gstrx.html#1018509  http://www.theserverside.com/article s/article.tss?l=Nuts-and-Bolts-of- Transaction-Processing http://www.theserverside.com/article s/article.tss?l=Nuts-and-Bolts-of- Transaction-Processing  http://java.sun.com/products/jts/java doc/index.html http://java.sun.com/products/jts/java doc/index.html

31. Reference cont’d  http://www- 128.ibm.com/developerworks/java/lib rary/j-jtp0305.html http://www- 128.ibm.com/developerworks/java/lib rary/j-jtp0305.html  http://www.codenotes.com/articles/a rticleAction.aspx?articleID=77 http://www.codenotes.com/articles/a rticleAction.aspx?articleID=77

32. QUESTIONS ????

33. Session Bean  A session bean is a type of enterprise bean; a type of EJB server-side component. Session bean components implement the javax.ejb.SessionBean interface and can be stateless or stateful. Stateless session beans are components that perform transient services; stateful session beans are components that are dedicated to one client and act as a server-side extension of that client.

34.  A smart component could check on the current status of the transaction and potentially save resources by not performing work that would be lost anyway. This would involve calling UserTransaction.getStatus(), which returns an int constant defined on the javax.transaction.Status interface:  STATUS_ACTIVE - A transaction is active.  STATUS_COMMITTED - The last active transaction was committed.  STATUS_COMMITTING - The last active transaction is committing.  STATUS_MARKED_ROLLBACK - Marked for rollback, perhaps by setRollbackOnly()

35.  STATUS_NO_TRANSACTION - No transaction is active  STATUS_PREPARED - A two-phase commit finished the prepared (1st) phase.  STATUS_PREPARING - A two-phase commit is inside the prepared phase.  STATUS_ROLLEDBACK - The last active transaction was aborted.  STATUS_ROLLING_BACK - The last active transaction is aborting.  STATUS_UNKNOWN - The transaction manager has no idea. (Try again later.)

36. Java Transaction APIs architecture: JTA

37.  In computing, Common Object Request Broker Architecture (CORBA) is a standard for software componentry, created and controlled by the Object Management Group (OMG). It defines APIs, communication protocol, and object/service information models to enable heterogeneous applications written in various languages running on various platforms to interoperate. CORBA therefore provides platform and location transparency for sharing well-defined objects across a distributed computing platform.software componentryObject Management GroupAPIsapplicationslanguagesdistributed computing  In a general sense CORBA “wraps” code written in some language into a bundle containing additional information on the capabilities of the code inside, and how to call it. The resulting wrapped objects can then be called from other programs (or CORBA objects) over the network. In this sense, CORBA can be considered as a machine- readable documentation format, similar to a header file but with considerably more information.programs objectsnetworkmachine- readableheader file  CORBA uses an interface definition language (IDL) to specify the interfaces that objects will present to the world. CORBA then specifies a “mapping” from IDL to a specific implementation language like C++ or Java. This mapping precisely describes how the CORBA data types are to be used in both client and server implementations. Standard mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, and Python. There are also non- standard mappings for Perl and Tcl implemented by ORBs written for those languages.interface definition languageC++Javadata typesAdaCC++LispSmalltalkJavaPythonPerlTclORBs  The CORBA IDL is only one example of an IDL.