Transaction Services in Component Frameworks Bruce Kessler Comp250CBS March 2, 2004

Overview Transactions as Concept Transactions as Concept A Transaction Standard A Transaction Standard Transactions in CORBA Transactions in CORBA Transactions in EJB Transactions in EJB Transactions in COM Transactions in COM

Transactions as Concept Definition Definition “An atomic unit of work. The work in a transaction must be completed as a whole; if any part of the transaction fails, the entire transaction fails.” - MSDN ODBC Glossary “An atomic unit of work. The work in a transaction must be completed as a whole; if any part of the transaction fails, the entire transaction fails.” - MSDN ODBC Glossary The standard that applies to Transactions is the ACID definition. The standard that applies to Transactions is the ACID definition.

Transactions as Concept ACID is an acronym describing attributes of a transaction: ACID is an acronym describing attributes of a transaction: ATOMIC ATOMIC CONSISTENT CONSISTENT ISOLATED ISOLATED DURABLE DURABLE

Transactions As Concept The concept of transactions grew out of RDBMS systems. Given the encapsulation and use of databases the concept fits cleanly. The concept of transactions grew out of RDBMS systems. Given the encapsulation and use of databases the concept fits cleanly. In component frameworks guaranteeing the same reliability across components for a distributed transaction is more difficult. In component frameworks guaranteeing the same reliability across components for a distributed transaction is more difficult.

Transactions as Concept For Example: For Example: Three systems across a distributed network that need to work in unison and guarantee that they have all completed their work before anyone can commit. If the network goes down, the rollback procedure has to be defined by the framework. Three systems across a distributed network that need to work in unison and guarantee that they have all completed their work before anyone can commit. If the network goes down, the rollback procedure has to be defined by the framework.

Transactions as Concept For Example: For Example: In a bank transaction there is a component that updates customer accounts and then another component that formats and prints checks. The output of this component is a printed check. If a rollback is called for by the account component, the check has to be ‘rolled back’. In a bank transaction there is a component that updates customer accounts and then another component that formats and prints checks. The output of this component is a printed check. If a rollback is called for by the account component, the check has to be ‘rolled back’.

Transaction as Concept Given the diversity of the component environment, how do you handle transaction processing and guarantee the data? Given the diversity of the component environment, how do you handle transaction processing and guarantee the data?

Transaction as Concept Given the diversity of the component environment, how do you handle transaction processing and guarantee the data? Given the diversity of the component environment, how do you handle transaction processing and guarantee the data? Transaction Standards Transaction Standards

A Transaction Standard A transaction standard shared by CORBA, EJB, and the COM framework is called XA. A transaction standard shared by CORBA, EJB, and the COM framework is called XA. XA is a Distributed Transaction Processing (DTP) protocol specified by the X/Open Organization. XA is a Distributed Transaction Processing (DTP) protocol specified by the X/Open Organization. The standard is now maintained by the Open Group. The standard is now maintained by the Open Group.

A Transaction Standard X/Open is known for being the standards body for the X Windowing System. X/Open is known for being the standards body for the X Windowing System. XA started as a system to allow for concurrency in operating systems. It was designed with an operating system component framework in mind. XA started as a system to allow for concurrency in operating systems. It was designed with an operating system component framework in mind.

A Transaction Standard The parts of the XA standard are: The parts of the XA standard are: Application Program (AP) Application Program (AP) Transaction Manager (TM) Transaction Manager (TM) Resource Manager (RM) Resource Manager (RM) (eg RDBMS, File System) (eg RDBMS, File System) The XA standard defines the interaction between the TM and the RM. The XA standard defines the interaction between the TM and the RM.

A Transaction Standard From Distributed Transaction Processing : The XA Specification from the Open Group

A Transaction Standard The fundamental process that underlies DTP is the two-phase commit. The fundamental process that underlies DTP is the two-phase commit. Phase 1: Poll all resources to determine whether they are able to commit. If one is not able to commit, all resources rollback. Phase 1: Poll all resources to determine whether they are able to commit. If one is not able to commit, all resources rollback. Phase 2: If all resources can commit, then send the commit signal to all resources. The resource then returns whether it committed successfully. Phase 2: If all resources can commit, then send the commit signal to all resources. The resource then returns whether it committed successfully.

Overview Transactions as Concept Transactions as Concept A Transaction Standard A Transaction Standard Transactions in CORBA Transactions in CORBA Transactions in EJB Transactions in EJB Transactions in COM Transactions in COM

Transactions in CORBA CORBA implements the XA DTP standard. CORBA implements the XA DTP standard. Objects in CORBA can opt out of providing support for transactions, even in the context of a transaction taking place in other objects in the same context. Objects in CORBA can opt out of providing support for transactions, even in the context of a transaction taking place in other objects in the same context. The following diagram is from the OMG’s Transaction Service Specification v1.4 Sept The following diagram is from the OMG’s Transaction Service Specification v1.4 Sept. 2003

Transactions in CORBA

The Transaction Service in CORBA is required to support flat transactions, but there is a description of nested transactions in the specification. The Transaction Service in CORBA is required to support flat transactions, but there is a description of nested transactions in the specification. Nested Transactions are transactions that have a hierarchical relationship with each other, that allow parts to rollback independently of other parts. Nested Transactions are transactions that have a hierarchical relationship with each other, that allow parts to rollback independently of other parts.

Transactions in CORBA An example of a nested transaction would allow a ‘parent’ transaction that encapsulates a ‘child’ transaction to continue if part of the ‘child’ transaction fails. An example of a nested transaction would allow a ‘parent’ transaction that encapsulates a ‘child’ transaction to continue if part of the ‘child’ transaction fails. Nested Transactions allow systems to carry out transactions that may have partially failed, but are still acceptable for a commit. Nested Transactions allow systems to carry out transactions that may have partially failed, but are still acceptable for a commit.

Overview Transactions as Concept Transactions as Concept A Transaction Standard A Transaction Standard Transactions in CORBA Transactions in CORBA Transactions in EJB Transactions in EJB Transactions in COM Transactions in COM

Transactions in EJB Enterprise Java Beans (EJB) use their containers to implement transactions but it is interoperable with the XA Standard. Enterprise Java Beans (EJB) use their containers to implement transactions but it is interoperable with the XA Standard. EJB Containers allow transaction management to be done with the Java Transaction API (JTA) which is a XA compliant implementation or through the container itself. EJB Containers allow transaction management to be done with the Java Transaction API (JTA) which is a XA compliant implementation or through the container itself.

Transactions in EJB Containers allow two types of transactions: Containers allow two types of transactions: Container Managed Transactions – which is usually configured in the ejb-jar.xml file and leaves transactions to the Container. Options are: Container Managed Transactions – which is usually configured in the ejb-jar.xml file and leaves transactions to the Container. Options are: NotSupported NotSupported Supports Supports Requires Requires RequiresNew RequiresNew Mandatory Mandatory Never Never

Transactions in EJB Additionally, transactions can be managed by beans themselves using EJB methods that allow DTP within the application server. Additionally, transactions can be managed by beans themselves using EJB methods that allow DTP within the application server.

Overview Transactions as Concept Transactions as Concept A Transaction Standard A Transaction Standard Transactions in CORBA Transactions in CORBA Transactions in EJB Transactions in EJB Transactions in COM Transactions in COM

Transactions in COM COM supports transactions through the Microsoft Transaction Server (MTS), which is also based on the XA standard. COM supports transactions through the Microsoft Transaction Server (MTS), which is also based on the XA standard. MTS allows COM components to act as resources in the XA resource model, with itself as the transaction manager. MTS allows COM components to act as resources in the XA resource model, with itself as the transaction manager. MTS is now incorporated into COM+. MTS is now incorporated into COM+.

Transactions in COM In terms of the XA framework, COM components are resources to be managed and the transaction manager is the Distributed Transaction Coordinator (DTC). In terms of the XA framework, COM components are resources to be managed and the transaction manager is the Distributed Transaction Coordinator (DTC). The DTC is responsible for handling distributed transactions and error recovery. Think of it as being like the container in EJB. The DTC is responsible for handling distributed transactions and error recovery. Think of it as being like the container in EJB.

Transactions in COM In COM+ there is a concept of Bring Your Own Transaction. In COM+ there is a concept of Bring Your Own Transaction. This means that transaction contexts can be assigned to components dynamically and they can inherit them from other components. This means that transaction contexts can be assigned to components dynamically and they can inherit them from other components. For example, a transaction that is happening within a CORBA OTS, could be associated with a COM+ component and the framework could accept this as the transaction context. For example, a transaction that is happening within a CORBA OTS, could be associated with a COM+ component and the framework could accept this as the transaction context.

References Transaction Service Specification from OMG, v1.4 Sept 2003 Distributed Transaction Processing : The XA Specification from the Open Group Java Transaction API Specification from Sun Microsystems COM+ Documentation from MSDN (msdn.microsoft.com)