| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
Most enterprise information systems support some form of transactions. For example, a typical JDBC database allows multiple SQL updates to be grouped in an atomic transaction.
Components should always access an enterprise information system under the scope of a transaction since this provides some guarantee on the integrity and consistency of the underlying data. Such systems can be accessed under a JTA transaction or a resource manager (RM) local transaction.
When an enterprise information system is accessed under the scope of a JTA transaction, any updates performed on the system will commit or roll back depending on the outcome of the JTA transaction. Multiple connections to information systems can be opened and all updates through the connections will be atomic if they are performed under the scope of a JTA transaction. The J2EE server is responsible for coordinating and propagating transactions between the server and the enterprise information system.
If the J2EE product supports multiple enterprise information systems in one transaction, a J2EE application can access and perform updates on multiple enterprise information systems atomically, without extra programming effort, by grouping all updates within a JTA transaction. Code Example 8.3 illustrates this use:
InitialContext ic = new InitialContext("java:comp/env");
DataSource db1 = (DataSource) ic.lookup("OrdersDB");
DataSource db2 = (DataSource) ic.lookup("InventoryDB");
Connection con1 = db1.getConnection();
Connection con2 = db2.getConnection();
UserTransaction ut = ejbContext.getUserTransaction();
ut.begin();
// perform updates to OrdersDB using connection con1
// perform updates to InventoryDB using connection con2
ut.commit();
| Code Example 8.3 Accessing Multiple Databases |
A resource manager local transaction (or local transaction) is a transaction specific to a particular enterprise information system connection. A local transaction is managed by the underlying enterprise information system resource manager. The J2EE platform usually does not have control or knowledge about any local transactions begun by components. Typically access to a transactional enterprise information system will be under a local transaction if no JTA transaction has been initiated. For example, if a servlet accesses a JDBC database without starting a JTA transaction, the database access will be under the scope of a local transaction, specific to the database.
Another scenario where enterprise information system access is under the scope of a local transaction is when the enterprise information system is not supported by the J2EE platform. For example, a standard J2EE platform is not required to support object-oriented databases. As a result, the platform would not be able to propagate any JTA transactions to the object-oriented databases and any access will be under local transactions.
It is recommended that enterprise information systems, such as databases, be accessed under the scope of a transaction. Accessing an enterprise information system under a transaction provides some guarantee on the consistency and integrity of the data.
We recommend that a component use JTA transactions whenever possible to access enterprise information systems. Using a JTA transaction allows multiple components accessing enterprise information systems to be grouped in a single transaction without adding extra logic. If a component marks the transaction as rollback only, all enterprise information system work will be rolled back automatically. With local transactions, each enterprise information system accessed will have to be committed or rolled back explicitly. In addition, components need extra logic to deal with individual enterprise information system rollbacks or failures.
A compensating transaction is a transaction or a group of operations that is used to undo the effect of a previously committed transaction. In the case where multiple access to enterprise information systems need to be grouped under a single transaction, but not all of the systems support JTA transactions, it will be necessary to define a compensating transaction for each enterprise information system access that is under the scope of a local transaction.
Compensating transactions are useful if a component needs to access an enterprise information system that does not support JTA transactions or access an enterprise information system that is not supported by a particular J2EE platform. In both cases, the enterprise information system will be accessed under the scope of a RM local transaction. If multiple enterprise information systems are involved, this creates the challenge of having to group all the work to multiple enterprise information systems into an atomic unit.
For example, suppose an application needs to perform an atomic operation that involves updating three enterprise information systems: two JDBC databases that supports JTA transactions and an enterprise resource planning system that does not. The application would need to define a compensating transaction for the update to the enterprise resource planning system. The approach is illustrated in Code Example 8.4.
updateERPSystem();
try {
UserTransaction.begin();
updateJDBCDatabaseOne();
updateJDBCDatabaseTwo();
UserTransaction.commit();
}
catch (RollbackException ex) {
undoUpdateERPSystem();
}
| Code Example 8.4 Compensating Transaction |
The methods updateERPSystem, updateJDBCDatabaseOne, and updateJDBCDatabaseTwo contain code to access and perform work on enterprise information systems. The undoUpdateERPSystem method contains code to undo the effect of updateERPSystem if the JTA transaction does not commit successfully.
This compensation logic should be encapsulated in a session enterprise bean with a bean-managed transaction. If the enterprise information system access logic is relatively simple, they can all reside in this bean. Otherwise, the enterprise bean can invoke other enterprise beans to access the enterprise information system. If an enterprise bean's only responsibility is to access an enterprise information system that does not support JTA transactions, its transaction attribute should be set to NotSupported. This denotes that a JTA transaction will not be used in the enterprise bean.
There are a few pitfalls regarding the use of compensating transactions:
- It is not always possible to undo the effect of a committed transaction. Consider Code Example 8.4. If the JTA transaction does not commit and for some reason the method
undoUpdateERPSystemdoes not succeed, the data will be left in an inconsistent state.- Atomicity could also be broken if the server crashes when a compensating transaction is used. For example, if the system crashes after the method
updateERPSystem, the updates to the two databases will not happen.- Inconsistent data might be seen by concurrent enterprise information system access. In this approach, non-JTA transactions are actually committed but may be undone subsequently. In the previous example, a concurrent enterprise information system access might see the update to the enterprise resource planning system which might be rolled back later. In other words, it sees uncommitted data.
An application that depends on compensating transactions must have extra logic to deal with potential failures and inconsistencies. The extra work and pitfalls of compensating transactions mean applications should avoid using them if possible. Instead, JTA transactions should be used as they provide a simple and safe way to achieve the ACID properties across multiple components and enterprise information systems.
An isolation level defines how concurrent transactions to an enterprise information system are isolated from one another. Enterprise information systems usually support the following the isolation levels:
ReadCommitted: This level prevents a transaction from reading uncommitted changes from other transactions.RepeatableRead: This level prevents a transaction from reading uncommitted changes from other transactions. In addition, it ensures that reading the same data multiple times will receive the same value even if another transaction modifies the data.Serializable: This level prevents a transaction from reading uncommitted changes from other transactions and ensures that reading the same data multiple times will receive the same value even if another transaction modifies the data. In addition, it ensures that if a query retrieves a result set based on a predicate condition and another transaction inserts data that satisfy the predicate condition, re-execution of the query will return the same result set.
Isolation level and concurrency are closely related. A lower isolation level typically allows greater concurrency, at the expense of more complicated logic to deal with potential data inconsistencies. A useful guideline is to use the highest isolation level provided by enterprise information systems that gives acceptable performance.
For consistency, all enterprise information systems accessed by a J2EE application should use the same isolation level. Currently, the J2EE specification does not define a standard way to set isolation levels when an enterprise information system is accessed under JTA transactions. If a J2EE product does not provide a way to configure the isolation level, the enterprise information system default isolation level will be used. For most relational databases, the default isolation level is ReadCommitted.
We recommend that you not change the isolation level within a transaction, especially if some work has already been done. Some enterprise information systems will force a commit if you attempt to change the isolation level.