Performing Distributed Transactions with a Transaction Manager

The middle tier of the JTA architecture is the Transaction Manager. The responsibility of the Transaction Manager is to manage the communication between the application and XA-Compliant resources. The transaction manager provides the ability to perform distributed transactions by coordinating and controlling the resources that are participating in the transaction. The application starts a transaction with the transaction manager, and then opens and communicates with the Tx DataSource objects that are participating in the distributed transaction. The application finally requests the transaction manager to commit all data storage modifications. The transaction manager performs a Two-Phase Commit operation, as explained in the "Two-Phase Commit (2PC)" section later in this chapter. If the transaction manager is unable to commit the transaction to all the participating resources, it will roll back the entire distributed transaction.

Note

The WebLogic JTA driver must be used to perform distributed transactions on WebLogic Platform. Refer to "Using the WebLogic JTA Driver" later in this chapter for further information.

XA-Compliant Resources

XA compliance refers to the X/Open XA interface specification, which defines the communication between a transaction manager and one or more resource managers. The role of the transaction manager is to coordinate and control all the resource managers that are participating in a distributed transaction. The X/ Open standards body developed the Distributed Transaction Processing (DTP) model and the XA interface to solve the problems of distributed transactions. The most significant problem is how to coordinate the commit or rollback of a transaction on distributed individual resources. The transaction manager ensures that all resources successfully complete the transaction, or all operations fail as a group . The JTA driver running in the WebLogic Server provides the transaction management for the distributed transaction. All database servers participating in the distributed transaction must therefore implement an XA-compliant resource manager.

Two-Phase Commit (2PC)

The WebLogic JTA driver, acting as the transaction manager, and the database servers, acting as resource managers, use the Two-Phase Commit protocol with presumed rollback. That is, if something goes wrong during the transaction, each resource manager automatically rolls back its portion of the transaction. In phase one, the transaction manager asks all resource managers to prepare to commit a transaction. If a resource manager is unable to commit, it automatically rolls back any work it performed on behalf of the transaction. In phase two, the transaction manager determines whether any resource managers were unable to commit. Based on the results of phase one, preparing to commit, the transaction manager instructs the resource managers to either commit or roll back.

Transaction Isolation Levels

The ACID properties require that database operations and transactions must be isolated from concurrency issues. The operations must complete with identical results whether being performed serially or concurrently. The JDBC specification provides Transaction Isolation Levels that allow the application to control the behavior of the database for concurrency issues. There are five levels, which are described in Table 16.5; however, you must review your JDBC driver and database documentation to determine which levels are available.

The transaction isolation levels guard against three conditions that may occur with concurrent access to a database:

• Dirty reads ” Refers to reading data that was written by another uncommitted transaction.

• Non-repeatable reads ” Occurs when a transaction rereads data and finds that the data has been modified by another transaction that was committed since the initial read.

• Phantom reads ” Occurs when a query is re-executed and the results are different because another transaction has committed changes to the data.

Table 16.5. The Five Transaction Isolation Levels

Level	Action
TRANSACTION_NONE	Makes no attempt to isolate the transaction from another transaction.
TRANSACTION_READ_UNCOMMITTED	Allows dirty reads, meaning that it selects the latest value whether or not it has been committed from another transaction.
TRANSACTION_READ_COMMITTED	Does not allow dirty reads, meaning that it always selects the most recently committed data. Warning: This level does not guarantee repeatable reads because new data may be committed between the read operations.
TRANSACTION_REPEATABLE_READ	Does not allow dirty or nonrepeatable reads. Warning: This level does not guarantee protection against phantom reads because new data may be committed to other tables with relationships to this table. REPEATABLE_READ is rarely used because the performance costs outweigh its limited benefits.
TRANSACTION_SERIALIZABLE	Does not allow dirty, nonrepeatble, or phantom reads. This is a trade-off between high reliability and low performance.

To set the Transaction Isolation Level, call the method setTransactionIsolation() on the Connection object. The parameter is one of the five public static constants defined in the Connection class. The field names are exactly the same as shown in Table 16.5.