| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
The J2EE architecture defines transactional behavior for three types of resource managers: JDBC-compliant databases, J2EE Connector-enabled information systems, and JMS providers. All three types of resource managers may be used within the scope of a single distributed transaction. Each type has somewhat different requirements and transactional semantics. This section describes these resource manager types and the requirements the J2EE platform specification places on them. It also explains their transactional semantics.
A J2EE product is required to provide transactional access to one JDBC resource per transaction. Transactional access to JDBC resources is available from servlets, JSP pages, and enterprise beans. Multiple components accessing the same JDBC resource within the scope of the same transaction are supported. For example, a servlet may start a transaction, modify a database, and invoke methods on an enterprise bean that modifies that same database, all within the scope of the same transaction.
Products that support access to multiple JDBC resources within a single transaction must do so with platform-specific APIs. Applications that use these features are not portable.
A J2EE product is required to support at least one JMS provider per transaction. Transaction access to a JMS provider is available from servlets, JSP pages, and enterprise beans. Like JDBC connections, multiple components, potentially in different tiers, must be able to access the JMS provider within the same transaction scope. As with JDBC databases, accessing multiple JMS providers within a single transaction requires platform-specific APIs, sacrificing portability.
The transactional semantics of JMS message transmission refers to the transmission of the message itself, not necessarily any side-effect that transmission may cause. Each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. Messages that are produced within a transaction are not immediately transmitted; instead, they are sent only once the transaction is committed. The messages are discarded if the transaction is rolled back. Similarly, messages are not consumed within a transaction until the transaction is committed. If the transaction is rolled back, messages will be redelivered and will remain available for consumption.
In JMS, transactions are never propagated between the sender and the recipient of a JMS message. In other words, the sender and the recipient of a JMS message can never be in the same transaction. The JMS transaction semantics provides atomicity on the sending and receiving of messages. For example, if an application sends two messages within a transaction T1, either both messages will be sent or they will both be discarded. On the recipient side, if both messages are delivered in a different transaction T2, the JMS provider will attempt to re-deliver the messages again if transaction T2 is rolled back. These are separate operations, and transaction T1 and T2 are independent of each other.
The transaction semantics of JMS presents one potential deadlock scenario for J2EE applications. Suppose an application A sends a JMS message to application B and suspends processing until it receives a message (for example, an acknowledgement message) from application B. If this work is done in a single transaction, application A will wait forever because the message from application A to B will not be sent until the transaction commits. To avoid this problem, the sending and receiving of messages in application A should be broken into two separate transactions.
The J2EE Connector architecture defines a standard architecture for integrating with heterogeneous EIS resources. It defines the contracts for a J2EE server as well as for resource adapters, which are system-level software drivers for specific EIS resources. These standard contracts provide pluggability between application servers and EISs.
A resource adapter can choose to support three different levels of transactions:
If a NoTransaction resource adapter is used as part of a JTA transaction, the action performed through the resource adapter will be independent of the transaction. In other words, the operations performed will not be rolled back even if the JTA transaction itself is rolled back.
If a LocalTransaction resource adapter is used in a JTA transaction, no other transactional resources (for example, JDBC or JMS access) can be used in the same transaction. This is because a LocalTransaction resource adapter does not support two-phase commit and thus cannot be mixed with other transactional resource managers in the same transaction.
The XATransaction resource adapter is the most flexible and can be mixed with other transactional resources in the same JTA transaction. For example, a J2EE application can update a JDBC database, send a JMS Message, and access an EIS resource in the same transaction provided the resource adapter used to access the EIS supports XATransaction. Note that this scenario is illegal if the resource adapter only supports LocalTransaction because a LocalTransaction resource adapter cannot be mixed with other transactional resources in the same transaction. This scenario is still valid if the resource adapter only supports the NoTransaction transaction level. However, the access to the EIS will not be part of the JTA transaction. Table 8.1 summarizes the behavior for resource adapters with different transactional levels.
Applications should use an XATransaction resource adapter whenever possible for maximum flexibility and data integrity. If an XATransaction resource adapter is not available, a LocalTransaction resource adapter can provide similar transaction behavior as long as there is only one resource adapter in the transaction. An application may need to use a compensating transaction (see Section 8.7.4 on page 269) if it is necessary to access multiple resources within a single transaction. An application should use a NoTransaction resource adapter only if transactional access to a particular EIS is not important.