| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
The following scenarios illustrate the use of transactions in a J2EE environment.
In Figure 8.1, a client invokes
enterprise bean X. Bean X accesses database A
using a JDBC connection. Then enterprise bean X calls another enterprise
bean Y. Y accesses database B. The J2EE
server and resource adapters for both database systems ensure that updates to
both databases are either all committed, or all rolled back.
Figure 8.1 Accessing Multiple Databases in the Same Transaction
An Application Component Provider does not have to write extra code to ensure transactional semantics. Enterprise beans X and Y access the database systems using the JDBC client access API. Behind the scenes, the J2EE server enlists the connections to both systems as part of the transaction. When the transaction is committed, the J2EE server and the resource managers perform a two-phase commit protocol to ensure atomic update of the two systems.
In Figure 8.2, a client invokes
the enterprise bean X, which updates data in enterprise information
system A, and then calls another enterprise bean Y
that is installed in another J2EE server. Enterprise bean Y performs
read-write access to enterprise information system B.
Figure 8.2 Accessing Multiple Enterprise Information Systems in the Same Transaction
When X invokes Y, the two J2EE servers cooperate to propagate the transaction context from X to Y. This transaction context propagation is transparent to the application code. At transaction commit time, the two J2EE servers use a distributed two-phase commit protocol to ensure that the two enterprise information systems are updated under a single transaction.