Transaction Services in Component Frameworks

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

2. Overview • Transactions as Concept • A Transaction Standard • Transactions in CORBA • Transactions in EJB • Transactions in COM

3. Transactions as Concept • 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 • The standard that applies to Transactions is the ACID definition.

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

5. Transactions As Concept • 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.

6. Transactions as Concept • 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.

7. Transactions as Concept • 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’.

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

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

10. A Transaction Standard • 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. • The standard is now maintained by the Open Group.

11. A Transaction Standard • 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.

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

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

14. A Transaction Standard • 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 2: If all resources can commit, then send the commit signal to all resources. The resource then returns whether it committed successfully.

15. Overview • Transactions as Concept • A Transaction Standard • Transactions in CORBA • Transactions in EJB • Transactions in COM

16. Transactions in CORBA • 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. • The following diagram is from the OMG’s Transaction Service Specification v1.4 Sept. 2003

17. Transactions in CORBA

18. 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. • Nested Transactions are transactions that have a hierarchical relationship with each other, that allow parts to rollback independently of other parts.

19. 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. • Nested Transactions allow systems to carry out transactions that may have partially failed, but are still acceptable for a commit.

20. Overview • Transactions as Concept • A Transaction Standard • Transactions in CORBA • Transactions in EJB • Transactions in COM

21. Transactions in EJB • 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.

22. Transactions in EJB • 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: • NotSupported • Supports • Requires • RequiresNew • Mandatory • Never

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

24. Overview • Transactions as Concept • A Transaction Standard • Transactions in CORBA • Transactions in EJB • Transactions in COM

25. Transactions in COM • 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 is now incorporated into COM+.

26. 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). • The DTC is responsible for handling distributed transactions and error recovery. Think of it as being like the container in EJB.

27. Transactions in COM • 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. • 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.

28. 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)