In effect, one business activity (bill payment) is executed under the scope of two separate transactions. In a flat transaction model, the only way to correctly control the scope of transactions that span multiple services is to reach an agreement beforehand on how these services will be combined for a business activity and to apply appropriate transaction policies for the services by agreement.
What if the check writing service were created and hosted by a different company? What if the check writing company did not want its deployment attributes to be dictated by Flute Bank? What if other customers (Flute Bank's competitor) of the check writing company wanted a contradictory transaction policy? Would it not be in Flute Bank's interest to have its bill payment transaction control the outcome of the business activity, regardless of whether the check writing company decided to start a new transaction or not?
A nested transaction model, shown in Figure 2, is one solution to the above problem. It allows transactions to consist of other transactions: a top-level transaction may contain subtransactions. In a nested transaction model, with respect to the above example, the bill payment service would start a top-level transaction (t). Both the account management service and the check writing service are free to start new transactions (ts1 and ts2). But both these subtransactions are within the scope of the top-level transaction (t). Transactions in a nested transaction model also adhere to the ACID properties of transactions—that is, t completes successfully only if ts1 and ts2 both complete successfully. If either subtransaction fails, the top-level transaction would fail, thereby guaranteeing atomicity.
Figure 2 Nested transactions
A nested transaction model allows services to be built independently and later combined into applications. Each service can determine the scope of its transaction boundaries. The application or service that orchestrates the combination of services controls the scope of the top-level transaction.
Java Transaction API (JTA)In a J2EE environment, the transaction manager has to communicate with the application server, the application program, and the resource managers, using a well-defined and standard API. The Java Transaction API (JTA) is defined precisely for this purpose. It does not specify how the transaction manager itself has to be implemented but how components external to the transaction manager communicate with it. The JTA defines a set of high-level interfaces that describe the contract between the transaction manager and three application components that interact with it: the application program, resource manager, and application server. These are described below. The next section describes the Java Transaction Service (JTS) specification—a related specification that deals with the implementation details of transaction managers.
- JTA contract between transaction managers and application programs. In J2EE applications, a client application or server EJB component whose transaction policy is managed in the bean code (TX_BEAN_MANAGED) can explicitly demarcate (i.e., start and stop) transactions. For this purpose, the application gets a reference to a user transaction object that implements the javax.transaction.UserTransaction interface. This interface defines methods, among others, that allow the application to commit, roll back, or suspend a transaction. The transaction that is started or stopped is associated with the calling user thread.
- In a Java client application, the UserTransaction object is obtained by looking up the application server's JNDI-based registry. There is no standard JNDI name for storing the UserTransaction reference, so the client application must know beforehand (usually by reading a configuration file) how to obtain the UserTransaction object from the application server's JNDI registry. In an EJB, the UserTransaction object is exposed through the EJBContext.
- JTA contract between transaction managers and application servers. J2EE containers are required to support container-managed transactions. The container demarcates transactions and manages thread and resource pooling. This requires the application server to work closely with the transaction manager. For example, in an EJB where the container has to manage transaction demarcation, the EJB container has to communicate with the transaction manager to start, commit, and suspend transactions. The J2EE application server and transaction manager communicate via the javax.transaction.TransactionManager interface.
- JTA contract between transaction managers and transactional resource managers. Resource managers provide an application access to resources, which can be databases, JMS queues, or any other transactional resource. An example of a global transaction is the one that changes a Flute Bank employee's address: it involves updating the employee master database (Oracle) and posting a message to a JMS queue (MQSeries) for the external payroll company (because payroll taxes can change based on employee address). For the transaction manager to coordinate and synchronize the transaction with different resource managers (in this example, Oracle and MQSeries), it must use a standards-based, well-known transaction protocol that both resource managers understand (such as X/Open XA).
- JTA defines the javax.transaction.xa.XAResource interface, which allows a transactional resource manager, such as a DBMSor JMS implementation, to participate in a global transaction. The XAResource interface is a Java mapping of the industry-standard X/Open XA. J2EE applications communicate to the resource managers via a resource adapter (e.g., JDBC connection), and JDBC 2.0 extensions support distributed transactions. JDBC 2.0 provides two interfaces that support JTA-compliant resources: the javax.sql.XAConnection and javax.sql.XADataSource.
- Similarly, JMS providers implement the javax.jms.XAConnection and the javax.jms.XASession interfaces in supporting JTA transaction managers.
Java Transaction Service
The JTA specification's main purpose is to define how a client application, the application server, and the resource managers communicate with the transaction manager. Because JTA provides interfaces that map to X/Open standards, a JTA-compliant transaction manager can control and coordinate a transaction that spans multiple resource managers (distributed transactions). JTA does not specify how a transaction manager is to be implemented, nor does it address how multiple transaction managers communicate with each other to participate in the same transaction. That is, it does not specify how a transaction context can be propagated from one transaction manager to another. The Java Transaction Service (JTS) specification addresses these concepts.
JTS specifies the implementation contracts for Java transaction managers. It is the Java mapping of the CORBAObject Transaction Service (OTS) 1.1 specification. The OTS specification defines a standard mechanism for generating and propagating a transaction context between transaction managers, using the IIOP protocol. JTS uses the OTS interfaces (primarily org.omg.CosTransactions and org.omg.CosTSPortability) for interoperability and portability. Because JTS is based on OTS, it is not unusual to find implementations that support transactions propagating from non-Java CORBA clients as well.
Within a JTS-compliant transaction manager implementation, a communication resource manager component handles incoming and outgoing transaction requests. Details of the interaction between the application server and a JTS transaction manager can be found in the JTS specification document.
In addition to being a Java mapping of OTS, the JTS specification also mandates that a JTS-compliant transaction manager implement all JTA interfaces—that is, a JTS-based transaction manager interfaces with an application program, the application server, and resource managers, using the JTA. Figure 3 shows the relationship between the application components involved in a transaction.
Figure 3 JTA transaction manager components
Source of this material
|This is material from Chapter 14: Transaction Management from the book Java Web Services Architecture (ISBN: 1-55860-900-8) written by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers. |
To access the full Table of Contents for the book
Page 3 of 3