Transaction Services with JTA and JTS
This material is from Chapter 14, Transaction Services with JTA and JTS, from the book J2EE Developer's Handbook (ISBN: 0-672-32348-6) written by Paul J. Perrone, Venkata S.R. "Krishna" R. Chaganti, and Tom Schwenk, published by Sams Publishing.
Chapter 14: Transaction Services with JTA and JTS
In this chapter, we describe more than the mere application of transactions to databases. We explore those services used to manage transactions in a distributed enterprise system. Distributed objects need to coordinate and define boundaries for access to shared resources. Transaction services provide such support. This chapter expands on the transaction problem and generic transaction service architecture, the CORBA Object Transaction Service (OTS), the Java Transaction API (JTA), and the Java Transaction Service (JTS). As you'll see, the JTS is a Java mapping of the OTS. Finally, we also touch on the latest developments in industry and with Java as it regards transactional Web services.
The JTA and OTS/JTS are all core underlying components that can be utilized by J2EE-based servers. The J2EE specification, in fact, requires that certain APIs defined by the JTA be incorporated into J2EE-compliant servers. Although the J2EE's declarative model for using transactions simplifies application programming, much of the literature and declarative programming conventions describing transaction usage with the J2EE is described in the context of JTA and OTS/JTS constructs and concepts. A basic understanding of the underlying transactions framework will help you make better decisions as an enterprise developer to determine what the best model for declaring transactions is for your components, as well as perhaps being useful for creating standalone distributed enterprise applications.
In this chapter, you will learn:
The concept of transactions and the problems encountered by distributed objects with transaction management.
How transaction services solve the problems encountered by distributed objects with transactions.
The CORBA Object Transaction Service as a standard distributed transaction service solution.
The Java Transaction API for specifying local Java interfaces between a transaction manager and the various distributed entities involved in a transaction.
The JTA high-level transaction manager interface for allowing an application server to control the boundaries of an application under control of an application server.
The JTA high-level application interface that allows a transaction-savvy application to delineate transaction boundaries.
The JTA mapping of the X/Open XA standard protocol that enables a resource manager to take part in a transaction controlled by an external transaction manager.
The Java Transaction Service for implementation of the OTS via a Java mapping, as well as the implementation of a Transaction Manager supporting the JTA specification.
The latest developments with Web service transaction standards and the Java APIs, such as JAXTX, that are being created to encapsulate such standards.
Recall from Chapter 2 in the discussion of transactions that we covered ACID principles. ACID stands for Atomicity, Consistency, Isolation, and Durability. Guaranteeing that your enterprise system adheres to the ACID principles is an important first step in understanding the need for transactions
Atomicity for a collection of operations can be very important for enterprise applications. For example, as illustrated in Figure 14.1, our BeeShirts.com application may desire to place a customer's order with a particular T-shirt supplier. The customer's order and associated credit-card information may then be used to charge the customer's account. If for some reason the order cannot be placed (for example, an item is out of stock), we would not want to charge the customer's account. Likewise, if for some reason the customer's account could not be charged (for example, the customer exceeded his maximum credit), we would not want to place the order with the supplier. Some means for treating these individual operations as an atomic and inseparable operation need to be provided. In enterprise applications, much more complicated requirements for atomicity can exist when many individual operations can have such a codependence.
Consistency of system state is also important for enterprise applications. As shown in Figure 14.2, the placement of an order without the charging of an order can lead to the display of inconsistent information. It could be particularly troublesome to a customer visiting your e-commerce site if she sees that her account has been charged for an order that does not exist. Similarly, it could be particularly troublesome to the e-commerce storefront owner to discover that an order has been placed with one of his suppliers but that a customer was never charged. Thus, consistency of system state is a key requirement for your applications. This involves making sure that state embedded in different distributed objects and database elements is consistent.
The isolation of dependent operation changes to the system should be restricted to the application inducing the operations. Figure 14.3 illustrates the case in which an application Bar does not see the effect of a placed order by an application Foo until the changes can be committed by Foo. Isolation of change is thus important to present a consistent and accurate view of the system to other applications. Applications like Bar can then see changes only when they are committed.
Finally, Figure 14.4 depicts the need for ensuring durability or dependability of system state changes. If a failure occurs during the processing of operations before a change can even be committed or rolled back, a certain level of assurance must be provided that the system will still remain in a stable state when it comes back online. Durability of a system ensures that the system still behaves appropriately even in the event of system failure during the processing of inseparable operations.
A transaction, as depicted in Figure 14.5, is a sequence of processing steps that either must all take place or must have no individual step take place at all. We can commit the transaction and make it permanent when all steps occur as an inseparable operation. When no steps are allowed to occur because one or more steps failed, we say that the transaction must be rolled back to the original system state. By building your enterprise systems with transactions, you can guarantee that your system follows the ACID principles.
Distributed transactions are particularly important for enterprise applications. Transactions may need to encapsulate operations that affect the state of the system where the elements making up the state reside in multiple distributed system locations as illustrated in Figure 14.6. Such a distributed system state may rest in a database or perhaps within another enterprise resource such as a distributed communications server.
Distributed transaction state.
Transactions may also need to encapsulate operations invoked by different distributed applications as illustrated in Figure 14.7.
Distributed transaction applications.