EJB.11.2 Sample Scenarios

This section describes several scenarios that illustrate the distributed transaction capabilities of the Enterprise JavaBeans architecture.

EJB.11.2.1 Update of Multiple Databases

The Enterprise JavaBeans architecture makes it possible for an application program to update data in multiple databases in a single transaction.

In Figure EJB.11-1, a client invokes the enterprise Bean X. X updates data using two database connections that the deployer configured to connect with two different databases, A and B. Then X calls another enterprise Bean Y. Y updates data in database C. The EJB server ensures that the updates to databases A, B, and C are either all committed or all rolled back.

Figure EJB.11-1. Updates to Simultaneous Databases

The application programmer does not have to do anything to ensure transactional semantics. The enterprise Beans X and Y perform the database updates using the standard JDBC API. Behind the scenes, the EJB server enlists the database connections as part of the transaction. When the transaction commits, the EJB server and the database systems perform a two-phase commit protocol to ensure atomic updates across all three databases.

EJB.11.2.2 Update of Databases via Multiple EJB Servers

The Enterprise JavaBeans architecture allows updates of data at multiple sites to be performed in a single transaction.

In Figure EJB.11-2, a client invokes the enterprise Bean X. X updates data in database A, and then calls another enterprise Bean Y that is installed in a remote EJB server. Y updates data in database B. The Enterprise JavaBeans architecture makes it possible to perform the updates to databases A and B in a single transaction.

Figure EJB.11-2. Updates to Multiple Databases in the Same Transaction

When X invokes Y, the two EJB servers cooperate to propagate the transaction context from X to Y. This transaction context propagation is transparent to the application-level code.

At transaction commit time, the two EJB servers use a distributed two-phase commit protocol (if the capability exists) to ensure the atomicity of the database updates.

EJB.11.2.3 Client-Managed Demarcation

A Java client can use the javax.transaction.UserTransaction interface to explicitly demarcate transaction boundaries. The client program obtains the javax.transaction.UserTransaction interface using JNDI API as defined in the Java 2 Platform, Enterprise Edition specification [EJB.10].

The EJB specification does not imply that the javax.transaction.UserTransaction is available to all Java clients . The Java 2 Platform, Enterprise Edition specification specifies the client environments in which the javax.transaction.UserTransaction interface is available.

A client program using explicit transaction demarcation may perform, via enterprise beans, atomic updates across multiple databases residing at multiple EJB servers, as illustrated in Figure EJB.11-3.

Figure EJB.11-3. Updates on Multiple Databases on Multiple Servers

The application programmer demarcates the transaction with begin and commit calls. If the enterprise beans X and Y are configured to use a client transaction (i.e., their methods have either the Required , Mandatory , or Supports transaction attribute), the EJB server ensures that the updates to databases A and B are made as part of the client's transaction.

EJB.11.2.4 Container-Managed Demarcation

Whenever a client invokes an enterprise bean, the container interposes on the method invocation. The interposition allows the container to control transaction demarcation declaratively through the transaction attribute set by the application assembler. (See Section EJB.11.4.1 for a description of transaction attributes.)

For example, if an enterprise bean method is configured with the Required transaction attribute, the container behaves as follows : If the client request is not associated with a transaction context, the container automatically initiates a transaction whenever a client invokes an enterprise bean method that requires a transaction context. If the client request contains a transaction context, the container includes the enterprise bean method in the client transaction.

Figure EJB.11-4 illustrates such a scenario. A non-transactional client invokes the enterprise bean X, and the invoked method has the Required transaction attribute. Because the message from the client does not include a transaction context, the container starts a new transaction before dispatching the remote method on X. X's work is performed in the context of the transaction. When X calls other enterprise beans (Y in our example), the work performed by the other enterprise beans is also automatically included in the transaction (subject to the transaction attribute of the other enterprise bean).

Figure EJB.11-4. Update of Multiple Databases from Non-Transactional Client

The container automatically commits the transaction at the time X returns a reply to the client.

EJB.11.2.5 Bean-Managed Demarcation

A session bean can use the javax.transaction.UserTransaction interface to programmatically demarcate transactions.

EJB.11.2.6 Interoperability with Non-Java Clients and Servers

Although the Enterprise JavaBeans architecture focuses on the Java API (and Java programming language) for writing distributed enterprise applications, it is desirable that such applications are also interoperable with non-Java clients and servers (Figure EJB.11-5).

Figure EJB.11-5. Interoperating with Non-Java Clients and/or Servers

A container can make it possible for an enterprise bean to be invoked from a non-Java client. For example, the CORBA mapping of the Enterprise JavaBeans architecture [EJB.8] allows any CORBA client to invoke any enterprise bean object on a CORBA-enabled server using the standard CORBA API.

Providing connectivity to existing server applications is also important. An EJB server may choose to provide access to existing enterprise applications, such as applications running under CICS on a mainframe. For example, an EJB server may provide a bridge that makes existing CICS programs accessible to enterprise beans. The bridge can make the CICS programs visible to the Java programming language “based developer as if the CICS programs were other enterprise beans installed in some container on the EJB server.

Note

It is beyond the scope of the Enterprise JavaBeans specification to define the bridging protocols that would enable such interoperability.