Nuts and Bolts of Transaction Processing

Introduction

Transaction management is one of the most crucial requirements forenterprise application development. Most of the large enterpriseapplications in the domains of finance, banking and electronic commercerely on transaction processing for delivering their businessfunctionality. Given the complexity of today’s business requirements,transaction processing occupies one of the most complex segments ofenterprise level distributed applications to build, deploy and maintain.

This article walks the reader through the following:

• What is a transaction? What is ACID?
• What are the issues in building transactional applications? Why is transaction management middleware important?
• What is the architecture of a typical transaction processing application? What are the responsibilities of various components of this architecture?
• What are the concepts involved with transaction management systems?
• What are the standards and technologies in the transaction management domain?

This article is not specific to any product, and so attempts to begeneric while describing various issues and concepts. This article doesnot aim to compare various transaction processingtechnologies/standards, and offers a study only.

What is a Transaction?

Enterprise applications often require concurrent access todistributed data shared amongst multiple components, to performoperations on data. Such applications should maintain integrity of data(as defined by the business rules of the application) under thefollowing circumstances:

• distributed access to a single resource of data, and
• access to distributed resources from a single application component.

In such cases, it may be required that a group of operations on(distributed) resources be treated as one unit of work. In a unit ofwork, all the participating operations should either succeed or fail andrecover together. This problem is more complicated when

• a unit of work is implemented across a group of distributed components operating on data from multiple resources, and/or
• the participating operations are executed sequentially or in parallel threads requiring coordination and/or synchronization.

In either case, it is required that success or failure of a unit ofwork be maintained by the application. In case of a failure, all theresources should bring back the state of the data to the previous state (i.e., the state prior to the commencement of the unit of work).

The concept of a transaction, and a transaction manager (or atransaction processing service) simplifies construction of suchenterprise level distributed applications while maintaining integrity ofdata in a unit of work.

A transaction is a unit of work that has the following properties:

• ATOMICITY: A transaction should be done or undone completely and unambiguously. In the event of a failure of any operation, effects of all operations that make up the transaction should be undone, and data should be rolled back to its previous state.
• CONSISTENCY: A transaction should preserve all the invariant properties (such as integrity constraints) defined on the data. On completion of a successful transaction, the data should be in a consistent state. In other words, a transaction should transform the system from one consistent state to another consistent state. For example, in the case of relational databases, a consistent transaction should preserve all the integrity constraints defined on the data.
• ISOLATION: Each transaction should appear to execute independently of other transactions that may be executing concurrently in the same environment. The effect of executing a set of transactions serially should be the same as that of running them concurrently. This requires two things:
• During the course of a transaction, intermediate (possibly inconsistent) state of the data should not be exposed to all other transactions.
• Two concurrent transactions should not be able to operate on the same data. Database management systems usually implement this feature using locking.
• DURABILITY: The effects of a completed transaction should always be persistent.

These properties, called as ACID properties,guarantee that a transaction is never incomplete, the data is neverinconsistent, concurrent transactions are independent, and the effectsof a transaction are persistent. For a brief description of what can gowrong in distributed transaction processing, see Fault Tolerance and Recovery in Transaction Processing Systems.

Issues in Building Transactional Applications

To elicit the issues involved in building transactional applications, consider an order capture and order process application with the architecture shown in Figure 1.

This application consists of two client components implementing theorder capture and order process operations respectively. These twooperations constitute a unit of work or transaction.The order capture and order process components access and operate onfour databases for products, orders, inventory and shipping informationrespectively. In this figure, while the dotted arrows indicate read-onlydata access, the continuous arrows are transactional operationsmodifying data. The following are the transactional operations in thisapplication:

• create order,
• update inventory,
• create shipping record, and
• update order status.

While implementing these operations as a single transaction, the following issues should be addressed:

1. The application should keep track of all transactional operations and the databases operated upon. The application should therefore define a context for every transaction to include the above four operations.
2. Since the order capture and order process transaction is distributed across two components, the transaction context should be global and be propagated from the first component to the second along with the transfer of control.
3. The application should monitor the status of the transaction as it occurs.
4. To maintain atomicity of the transaction, the application components, and/or database servers should implement a mechanism whereby changes to databases could be undone without loss of consistency of data.
5. To isolate concurrent transactions on shared data, the database servers should keep track of the data being operated upon, and lock the data during the course of a transaction.
6. The application should also maintain association between database connections and transactions.
7. To implement reliable locking, the application components should notify the database servers of transaction termination.

Transaction Processing – Architecture

Having seen the issues in building transactional applications fromscratch, consider the same application built around a transactionprocessing architecture as shown in Figure 2. Note that, although there are several architectures possible, as will be discussed in a later section, the one shown in Figure 2 represents the essential features.

This architecture introduces a transaction manager and a resourcemanager for each database (resource). These components abstract most ofthe transaction specific issues from application components (OrderCapture and Order Process), and share the responsibility ofimplementation of transactions. The various components of thisarchitecture are discussed below.

Application Components

• Create and demarcate transactions
• Propagate transaction context
• Operate on data via resource managers

Application components are clients for the transactional resources.These are the programs with which the application developer implementsbusiness transactions.

With the help of the transaction manager, these components createglobal transactions, propagate the transaction context if necessary, andoperate on the transactional resources with in the scope of thesetransactions. These components are not responsible for implementingsemantics for preserving ACIDproperties of transactions. However, as part of the application logic,these components generally make a decision whether to commit or rollbacktransactions.

Resource Managers

• Enlist resources with the transaction manager
• Participate in two-phase commit
  and recovery protocol

A resource manager is a component that manages persistent and stabledata storage system, and participates in the two phase commit andrecovery protocols with the transaction manager.

A resource manager is typically a driver or a wrapper over a stablestorage system, with interfaces for operating on the data (for theapplication components), and for participating in two phase commit andrecovery protocols coordinated by a transaction manager. This componentmay also, directly or indirectly, register resources with thetransaction manager so that the transaction manager can keep track ofall the resources participating in a transaction. This process is calledas resource enlistment. For implementing the two-phase commit and recovery protocols, the resource manager should implement supplementary mechanisms using which recovery is possible.

Resource managers provide two sets of interfaces: one set for theapplication components to get connections and perform operations on thedata, and the other set for the transaction manager to participate inthe two-phase commit and recovery protocol.

Transaction Manager

• Establish and maintain transaction context
• Maintain association between a transaction and the participating resources.
• Initiate and conduct two-phase commit and recovery protocol with the resource managers.
• Make synchronization calls to the application components before beginning and after end of two-phase commit and recovery process

The transaction manager is the core component of a transactionprocessing environment. Its primary responsibilities are to createtransactions when requested by application components, allow resource enlistment and delistment, and to conduct the two-phase commit or recovery protocol with the resource managers.

A typical transactional application begins a transaction by issuing arequest to a transaction manager to initiate a transaction. Inresponse, the transaction manager starts a transaction and associates itwith the calling thread. The transaction manager also establishes atransaction context. All application components and/or threadsparticipating in the transaction share the transaction context. Thethread that initially issued the request for beginning the transaction,or, if the transaction manager allows, any other thread may eventuallyterminate the transaction by issuing a commit or rollback request.

Before a transaction is terminated, any number of components and/orthreads may perform transactional operations on any number oftransactional resources known to the transaction manager. If allowed bythe transaction manager, a transaction may be suspended or resumedbefore finally completing the transaction.

Once the application issues the commit request, the transactionmanager prepares all the resources for a commit operation (by conductinga voting), and based on whether all resources are ready for a commit ornot, issues a commit or rollback request to all the resources.

The following sections discuss various concepts associated with transaction processing.

Transaction Processing – Concepts

Transaction Demarcation

A transaction can be specified by what is known as transactiondemarcation. Transaction demarcation enables work done by distributedcomponents to be bound by a global transaction. It is a way of markinggroups of operations to constitute a transaction.

The most common approach to demarcation is to mark the threadexecuting the operations for transaction processing. This is called asprogrammatic demarcation. The transaction so established can besuspended by unmarking the thread, and be resumed later by explicitlypropagating the transaction context from the point of suspension to thepoint of resumption.

The transaction demarcation ends after a commit or a rollbackrequest to the transaction manager. The commit request directs all theparticipating resources managers to record the effects of the operationsof the transaction permanently. The rollback request makes the resourcemanagers undo the effects of all operations on the transaction.

An alternative to programmatic demarcation is declarativedemarcation. Component based transaction processing systems such asMicrosoft Transaction Server, and application servers based on theEnterprise Java Beans specification support declarative demarcation. Inthis technique, components are marked as transactional at the deploymenttime. This has two implications. Firstly, the responsibility ofdemarcation is shifted from the application to the container hosting thecomponent. For this reason, this technique is also called as containermanaged demarcation. Secondly, the demarcation is postponed fromapplication build time (static) to the component deployment time(dynamic).

Transaction Context and Propagation

Since multiple application components and resources participate in atransaction, it is necessary for the transaction manager to establishand maintain the state of the transaction as it occurs. This is usuallydone in the form of transaction context.

Transaction context is an association between the transactionaloperations on the resources, and the components invoking the operations.During the course of a transaction, all the threads participating inthe transaction share the transaction context. Thus the transactioncontext logically envelops all the operations performed on transactionalresources during a transaction. The transaction context is usuallymaintained transparently by the underlying transaction manager.

Resource Enlistment

Resource enlistment is the process by which resource managers informthe transaction manager of their participation in a transaction. Thisprocess enables the transaction manager to keep track of all theresources participating in a transaction. The transaction manager usesthis information to coordinate transactional work performed by theresource managers and to drive two-phase commit and recovery protocol.

At the end of a transaction (after a commit or rollback) thetransaction manager delists the resources. Thereafter, associationbetween the transaction and the resources does not hold.

Two-Phase Commit

This protocol between the transaction manager and all the resourcesenlisted for a transaction ensures that either all the resource managerscommit the transaction or they all abort. In this protocol, when theapplication requests for committing the transaction, the transactionmanager issues a prepare request to all the resource managers involved.Each of these resources may in turn send a reply indicating whether itis ready for commit or not. Only when all the resource managers areready for a commit, does the transaction manager issue a commit requestto all the resource managers. Otherwise, the transaction manager issues arollback request and the transaction will be rolled back.

Transaction Processing – Standards and Technologies

X/Open Distributed Transaction Processing Model

The X/Open Distributed Transaction Processing (DTP) model is adistributed transaction processing model proposed by the Open Group, avendor consortium. This model is a standard among most of the commercialvendors in transaction processing and database domains.

This model consists of four components:

1. Application Programs to implement transactional operations.
2. Resource Managers as discussed above.
3. Transaction Managers as discussed above.
4. Communication Resource Manager to facilitate interoperability between different transaction managers in different transaction processing domains.

This model also specifies the following interfaces:

1. TX Interface: This is an interface between the application program and the transaction manager, and is implemented by the transaction manager. This interface provides transaction demarcation services, by allowing the application programs to bound transactional operations within global transactions. This interface consists of the following functions:
   Function Purpose tx_open Opens the transaction manager and the set of associated
   resource managers. tx_close Closes the transaction manager and the set of associated
   resource managers. tx_begin Begins a new transaction. tx_rollback Rolls back the transaction. tx_commit Commits the transaction. tx_set_commit_return Commits the transaction. tx_set_transaction_control Switches between chained and unchained mode. In the case of chained transactions, the work is broken into pieces with each piece being under control of a flat transaction. Once a piece of work is complete it is committed or rolled back independent of the state of the other pieces. tx_set_transaction_timeout Sets a transaction timeout interval. tx_info Returns transaction information such as its identifier, state of the transaction etc. Table 1: TX Interface of X/Open DTP Model

2. XA Interface: This is a bidirectional interface between resource managers and transaction managers. This interface specifies two sets of functions. The first set, called as xa_*() functions are implemented by resource managers for use by the transaction manager.
   Function Purpose xa_start Directs a resource manager to associate the subsequent requests by application programs to a transaction identified by the supplied identifier. xa_end Ends the association of a resource manager with the transaction. xa_prepare Prepares the resource manager for the commit operation. Issued by the transaction manager in the first phase of the two-phase commit operation. xa_commit Commits the transactional operations. Issued by the transaction manager in the second phase of the two-phase commit operation. xa_recover Retrieves a list of prepared and heuristically committed or heuristically rolled back transactions xa_forget Forgets the heuristic transaction associated with the given transaction identifier Table 2: XA Interface of X/Open DTP Model for the transaction manager

   The second set of functions, called as ax_*() functions, are implemented by the transaction manager for use by resource managers.

   Function Purpose ax_reg Dynamically enlists with the transaction manager. ax_unreg Dynamically delists from the transaction manager. Table 3: AX Interface of X/Open DTP Model for resource managers

3. XA+ Interface: This interface is used to support global transactions across different transaction manager domains via communication resource managers.
4. TXRPC Interface: This interface provides portability for communication between application programs within a global transaction.
5. CRM-OSI TP: An interface between a communication resource manager and the OSI transaction processing services.

The X/Open DTP model is well established in the industry. A number of commercial transaction management products, such as TXSeries/Encina (from Tranarc, a wholly owned subsidiary of IBM), Tuxedo and TopEnd (both from BEA Systems), and AT&T GIS support the TX interface. Although Microsoft’s Transaction Serverdoes not support the TX interface, it can interoperate with XAcompliant databases, such as Oracle. Similarly, most of the commercialdatabases such as Oracle, Sybase, Informix and Microsoft SQL Server, andmessaging middleware products like IBM’s MQSeries, and Microsoft’s MSMQ Server provide an implementation of the XA interface.

OMG Object Transaction Service

Object Transaction Service (OTS) is a distributed transaction processing service specified by the Object Management Group (OMG). This specification extends the CORBA model and defines a set of interfaces to perform transaction processing across multiple CORBA objects.

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.
• The various objects in this model communicate via CORBA method calls over IIOP.

However, the OTS is interoperable with X/Open DTP model. Anapplication using transactional objects could use the TX interface withthe transaction manager for transaction demarcation.

The OTS architecture consists of the following components:

• Transaction Client: A program or object that invokes operations on transactional objects.
• 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: A collection of one or more transactional objects.
• Recoverable Server: A collection of objects, of which at least one of which is recoverable.
• Resource Object: A resource object is an object in the transaction service that is registered for participation in the two-phase commit and recovery protocol.

In addition to the usual transactional semantics, the CORBA OTS provides for the following:

• 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. Subtransactions can be committed or rolled back without committing or rolling back the parent transaction. However, the results of a commit operation are contingent upon the commitment of all the transaction’s ancestors. The main advantage of this model is that transactional operations can be controlled at a finer granularity. 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.
• 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.

The following are the principal interfaces in the CORBA OTS specification.

• Transaction demarcation (begin, commit, rollback, rollback_only, set_time_out)
• Status of the transaction (get_status)
• Name of the transaction (get_transaction_name)
• Transaction context (get_control)

• Status of the transaction (get_status, get_parent_status, get_top_level_status)
• Transaction information (is_same_transaction, is_related_transaction, is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction, hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext)
• Resource enlistment (register_resource, register_subtrans_aware)
• Registration of synchronization objects (register_synchronization)
• Set the transaction for rollback (rollback_only)
• Create subtransactions (create_subtransaction)

The following products offer implementations of the OTS: Integrated Transaction Service (from Inprise), OrbixOTM (from Iona), OTSARjuna (from Arjuna Solutions Limited), and TPBroker (from Hitachi Software).

JTA and JTS

The Java Transaction Service and the Java Transaction API are the latest entrants into the enterprise distributed computing arena. As a part of the enterprise Java initiative, Sun Microsystems Inc. proposed these specifications in early 1999.

JTS specifies the implementation of a Java transaction manager. Thistransaction manager supports the JTA, using which application serverscan be built to support transactional Java applications. Internally theJTS implements the Java mapping of the OMG OTS 1.1 specifications. TheJava mapping is specified in two packages: org.omg.CosTransactions and org.omg.CosTSPortability.Although the JTS is a Java implementation of the OMG OTS 1.1specification, the JTA retains the simplicity of the XA and TXfunctional interfaces of the X/Open DTP model.

The JTA specifies an architecture for building transactionalapplication servers and defines a set of interfaces for variouscomponents of this architecture. The components are: the application,resource managers, and the application server, as shown in Figure 3.

The JTS thus provides a new architecture for transactionalapplication servers and applications, while complying with the OMG OTS1.1 interfaces internally. This allows the JTA compliant applications tointeroperate with other OTS 1.1 complaint applications through thestandard IIOP.

As shown in Figure 3,in the Java transaction model, the Java application components canconduct transactional operations on JTA compliant resources via the JTS.The JTS acts as a layer over the OTS. The applications can thereforeinitiate global transactions to include other OTS transaction managers,or participate in global transactions initiated by other OTS complianttransaction managers.

For more details on JTS and JTA, see Java Transaction Service.

Microsoft Transaction Server

The Microsoft Transaction Server (MTS) is a component based transaction server for components based on the Microsoft’s Component Object Model(COM). The MTS programming model provides interfaces for buildingtransactional COM components, while the MTS runtime environment providesa means to deploy and manage these components and manage transactions.Using the MTS, work done by multiple COM components can be composed intoa single transaction.

Unlike other technologies discussed in this section, MTS is aproduct and is not based on open specifications. Also note that,although the MTS environment offers several other features such asresource pooling, object recycling, access control etc., this sectionfocuses only on the transactional capabilities of MTS, and attempts tomap the various transaction management concepts to the MTS environment.

MTS Architecture

The high level architecture of MTS is shown in Figure 4.

The MTS environment consists of the following:

1. MTS Run-time: It is the environment where instances of MTS components execute and be managed. The MTS run-time provides for deployment and management of MTS components. It has the following features:
   • Management of distributed transactions
   • Automatic management of processes and threads
   • Management of objects (creation, pooling and recycling)
   • Distributed security service to control object creation and usage
2. MTS Explorer: This is a graphical user interface driven tool for deploying and managing MTS components on the MTS run-time. The MTS Explorer can also be used to monitor transactions with the Distributed Transaction Coordinator.
3. Distributed Transaction Coordinator (DTC): DTC is the transaction manager for MTS.
4. MTS API: The MTS API (in Microsoft Visual Basic?, Microsoft Visual C++? and Microsoft Visual J++?) provides certain interfaces and concrete classes for building transactional components.
5. Resource Dispensers: An MTS resource dispenser manages nondurable shared data on behalf of MTS applications. MTS provides two resource dispensers:
   • ODBC Resource Dispenser: The ODBC resource dispenser is essentially a ODBC driver manager with the following additional capabilities:
     • Manage pools of connections to ODBC compliant databases, including reclamation and reuse of connections)
     • Enlist and delist database connections on MTS context objects.
   • Shared Property Manager: The MTS shared property manager manages applications-wide process-specific properties (name-value pairs) and provides synchronized access this data.
6. Resource Manager: For a resource manager to participate in MTS transactions, it must support one of the following protocols:
   • OLE Transactions: This is a COM based two-phase commit protocol used by resource managers to participate in transactions coordinated by the DTC.
   • X/Open DTP XA Protocol: With this protocol, the MTS requires a OLE Transactions to XA mapper. This mapper is provided by the MTS SDK.

MTS Objects and Transaction Context

An MTS object is an instance of an MTS component (a componentdeployed on MTS, and managed by MTS). For each MTS object, the MTScreates and maintains a context object (ObjectContext) whichprovides execution context for an MTS object. The context object alsomaintains information of transaction context. Resource dispensers andthe DTC can access this transaction context information for transactiondemarcation, resource enlistment, delistment, two-phase commitetc. Note that, in MTS, the transaction context information ismaintained with each MTS object, as opposed to a single transactioncontext object for all the objects participating in a transaction.

Transaction Outcome

Each MTS object can participate in determining the outcome of a transaction by calling one of the methods on the ObjectContext object:

• SetComplete: Informs the MTS that the object has successfully completed its work, and its work can be committed.
• SetAbort: Informs the MTS that the object’s work can not be committed.
• EnableCommit: The object’s work is not necessarily done, but its transactional work can be committed in the current form.
• DisableCommit: Informs the MTS the object’s work can not be committed in the current form.

Transaction Demarcation

MTS allows both programmatic and declarative demarcation oftransactions. Declarative demarcation is compulsory for all componentsdeployed on the MTS. In addition, MTS clients can also initiative andend transactions programmatically.

• Declarative Demarcation: Depending on an MTS component’s transaction property, MTS automatically begins a transaction on behalf of the application. The following transaction properties (that can be set at the deployment time) are possible:
  1. Requires Transaction: Instances of the component always execute within the context of a transaction. It is expected that the invoking object is being executing in the context of a transaction.
  2. Requires New Transaction: Instances of the component must execute within their own transactions, irrespective of whether or not the invoking object has started a transaction.
  3. Supports Transaction: Instances of the component can execute within the scope of the invoking object’s transaction (if there is one). This implies that the component is transaction-safe.
  4. Does not Support Transaction: Instances of the component do not execute with in the scope of any transaction. MTS does not associate the work done by such objects with any transaction.
• Programmatic Demarcation: MTS clients can demarcate transactions programmatically using the TransactionContext object. A client can begin a transaction by creating an instance of the TransactionContext object, and end the transaction by calling Commit or Abort methods of this object. All MTS objects created within these boundaries using the TransactionContext object will execute under the same transaction context (except when the component is set to require a new transaction, or does not support a transaction). MTS implicitly maintains the association between the TransactionContext object and the transaction.

Resource Enlistment

MTS does automatic resource enlistment. When a MTS object requeststhe resource dispenser for a connection to a resource, the resourcedispenser obtains the calling object’s transaction context, andregisters the connection with it.

Although MTS is available for Microsoft Windows platforms only, MTScan interoperate with resource managers complying to the XA protocol,and such resource managers operating on non-Windows platforms canparticipate in transactions coordinated by the DTC.

For more information on MTS, refer to the MSDN library. For a quick but elaborate compilation of features of MTS vis-a-vis other competing technologies, refer to MTS FAQ.

Enterprise Java Beans

Enterprise Java Beans (EJB) is a technology specification from Sun Microsystems Inc.that specifies a framework for building component-based distributedapplications. Application servers conforming to this technology arebeginning to appear from various vendors over the past six months, whilethe specification is being improved currently by Sun Microsystems Inc.

As an application server framework, the EJB servers addresstransaction processing, resource pooling, security, threading,persistence, remote access, life cycle etc. However, as with the case ofMTS, this section focuses only on distributed transactional model ofthe EJB framework.

The EJB framework specifies construction, deployment and invocation of components called as enterprise beans.The EJB specification classifies enterprise beans into two categories:entity beans and session beans. While entity beans abstract persistentdomain data, session beans provide for session specific applicationlogic. Both types of beans are maintained by EJB compliant servers inwhat are called as containers. A container provides the run timeenvironment for an enterprise bean.

Figure 5shows a simplified architecture of transaction management in EJBcompliant application servers. This figure shows only the essentialinteractions between the constituent parts of the architecture.

An enterprise bean is specified by two interfaces: the homeinterface and the remote interface. The home interface specifies how abean can created or found. With the help of this interface, a client oranother bean can obtain a reference to a bean residing in a container onan EJB server. The remote interface specifies application specificmethods that are relevant to entity or session beans.

Clients obtain references to home interfaces of enterprise beans via the Java Naming and Directory Interface(JNDI) mechanism. An EJB server should provide a JNDI implementationfor any naming and directory server. Using this reference to the homeinterface, a client can obtain a reference to the remote interface. Theclient can then access methods specified in the remote interface. TheEJB specification specifies the Java Remote Method Invocation (RMI) asthe application level protocol for remote method invocation. However, animplementation can use IIOP as the wire-level protocol.

In Figure 5,the client first obtains a reference to the home interface, and then areference to an instance of Bean A via the home interface. The sameprocedure is applicable for instance of Bean A to obtain a reference andinvoke methods on an instance of Bean B.

EJB Transaction Model

The EJB framework does not specify any specific transaction service(such as the JTS) or protocol for transaction management. However, thespecification requires that the javax.transaction.UserTransactioninterface of the JTS be exposed to enterprise beans. This interface isrequired for programmatic transaction demarcation as discussed in thenext section.

Similar to the MTS, the EJB framework provides for declarativedemarcation of transactions. The container performs automaticdemarcation depending on the transaction attributes specified at thetime of deploying an enterprise bean in a container.

The following attributes determine how transactions are created.

1. NotSupported: The container invokes the bean without a global transaction context.
2. Required: The container invokes the bean within a global transaction context. If the invoking thread already has a transaction context associated, the container invokes the bean in the same context. Otherwise, the container creates a new transaction and invokes the bean within the transaction context.
3. Supports: The bean is transaction-ready. If the client invokes the bean within a transaction, the bean is also invoked within the same transaction. Otherwise, the bean is invoked without a transaction context.
4. RequiresNew: The container invokes the bean within a new transaction irrespective of whether the client is associated with a transaction or not.
5. Mandatory: The container must invoke the bean within a transaction. The caller should always start a transaction before invoking any method on the bean.

Transaction Demarcation

The EJB framework supports three types of transaction demarcation.

• Declarative Demarcation: This is also called as container managed demarcation. The container demarcates transactions on behalf of the bean. The required attribute is specified in a deployment descriptor at the time of deploying the bean on an EJB server. The bean can use the javax.ejb.EJBContext.setRollbackOnly() method to mark the transaction for rollback.
• Bean Managed Demarcation: This is similar to the client-managed demarcation.
• Client Managed Demarcation: Java clients can use the javax.transaction.UserTransaction interface to demarcate transactions programmatically.

Resource Enlistment

Resource enlistment is automatic with EJB. The EJB containersautomatically enlists connections to EJB-aware resource managerswhenever a bean obtains a connection.

Application Synchronization

The EJB specification provides the javax.ejb.SessionSynchronization interface for application synchronization. When implemented by a bean, the container calls the afterBegin, beforeCompletion and afterCompletion methods for application synchronization during the two-phase commit process.

There are several vendors who currently offer application serverscomplying to the EJB 1.0 specification. Some of the products are WebLogic from BEA Systems Inc., GemStone/J from GemStone Systems Inc., NetDynamics from Sun Microsystems Inc., Oracle Application Server from Oracle Corporation, and PowerTier for EJB from Persistence Software Inc.. Refer to the EJB Directoryfor a listing of EJB application servers and EJB-aware databaseservers. The specification is currently undergoing a major overhaul, andproducts complying to the new standard are expected by late 1999 orearly 2000.

In summary, the EJB framework provides features almost similar tothe MTS. Both the technologies allow component-based transactionaldistributed applications, and abstract the process of transactiondemarcation from application components.

Conclusion

Transaction processing has always been complex and critical.However, with the advent of MTS and EJB, transaction processing hascaught the interest and attention of both developers and ITorganizations simultaneously. This is not without reason. These recenttechnologies simplify distributed transaction management, and are fueledby three major developments:

• Distributed Computing: The two competing distributed computing models (CORBA and COM/DCOM) simplified distributed computing.
• Component Based Development: Based on the above interface centric paradigms, component based distributed application development
  has become a reality.
• Object Orientation: The maturity of object-oriented programming assisted by design patterns and frameworks, made implementation of these technologies feasible.

In addition, these technologies address the scalability and robustness that are required for today’s enterprise applications.

The purpose of this document is to focus on the issues and conceptsinvolved in distributed transaction management. By no means this is acomprehensive enough to cover all the finer details of the underlyingtechnologies. At the same time, this document does not attempt tocompare technologies, but attempts to map various concepts to each ofthe technologies. Only the nuts and the bolts are discussed, not hownuts and bolts are made, and not how machines are built with them.

(Written sometime in 1999)