EJB.11.7 Access from Multiple Clients in the Same Transaction Context

This section describes a more complex distributed transaction scenario, and specifies the container's behavior required for this scenario.

EJB.11.7.1 Transaction "Diamond" Scenario with an Entity Object

An entity object may be accessed by multiple clients in the same transaction. For example, program A may start a transaction, call program B and program C in the transaction context, and then commit the transaction. If programs B and C access the same entity object, the topology of the transaction creates a diamond (Figure EJB.11-6).

Figure EJB.11-6. Transaction Diamond Scenario with Entity Object

An example (not realistic in practice) is a client program that tries to perform two purchases at two different stores within the same transaction. At each store, the program that is processing the client's purchase request debits the client's bank account.

It is difficult to implement an EJB server that handles the case in which programs B and C access an entity object through different network paths. This case is challenging because many EJB servers implement the EJB container as a collection of multiple processes, running on the same or multiple machines. Each client is typically connected to a single process. If clients B and C connect to different EJB container processes, and both B and C need to access the same entity object in the same transaction, the issue is how the container can make it possible for B and C to see a consistent state of the entity object within the same transaction. ^[4]

^[4] This diamond problem applies only to the case when B and C are in the same transaction.

The above example illustrates a simple diamond. We use the term diamond to refer to any distributed transaction scenario in which an entity object is accessed in the same transaction through multiple network paths.

Note that in the diamond scenario the clients B and C access the entity object serially . Concurrent access to an entity object in the same transaction context would be considered an application programming error, and it would be handled in a container-specific way.

Note that the issue of handling diamonds is not unique to the EJB architecture. This issue exists in all distributed transaction processing systems.

The following subsections define the responsibilities of the EJB roles when handling distributed transaction topologies that may lead to a diamond involving an entity object.

EJB.11.7.2 Container Provider's Responsibilities

This subsection specifies the EJB container's responsibilities with respect to the diamond case involving an entity object.

The EJB specification requires that the container provide support for local diamonds. In a local diamond, components A, B, C, and D are deployed in the same EJB container.

The EJB specification does not require an EJB container to support distributed diamonds. In a distributed diamond, a target entity object is accessed from multiple clients in the same transaction through multiple network paths, and the clients (programs B and C) are not enterprise beans deployed in the same EJB container as the target entity object.

If the container provider chooses not to support distributed diamonds, and if the container can detect that a client invocation would lead to a diamond, the container should throw the java.rmi.RemoteException to the client.

If the container provider chooses to support distributed diamonds, it should provide a consistent view of the entity state within a transaction. The container provider can implement the support in several ways. (The options that follow are illustrative , not prescriptive.)

Always instantiate the entity bean instance for a given entity object in the same process, and route all clients' requests to this process. Within the process, the container routes all the requests within the same transaction to the same enterprise bean instance.
Instantiate the entity bean instance for a given entity object in multiple processes, and use the ejbStore and ejbLoad methods to synchronize the state of the instances within the same transaction. For example, the container can issue ejbStore after each business method, and issue ejbLoad before the start of the next business method. This technique ensures that the instance used by a one client sees the updates done by other clients within the same transaction.

An illustration of the second approach is shown in Figure EJB.11-7. The illustration is illustrative, not prescriptive for the container implementors.

Figure EJB.11-7. Handling of Diamonds by a Multi-Process Container

Program B makes a call to an entity object representing Account 100. The request is routed to an instance in process 1. The container invokes ejbLoad on the instance. The instance loads the state from the database in the ejbLoad method. The instance updates the state in the business method. When the method completes, the container invokes ejbStore . The instance writes the updated state to the database in the ejbStore method.

Now program C makes a call to the same entity object in the same transaction. The request is routed to a different process (2). The container invokes ejbLoad on the instance. The instance loads the state from the database in the ejbLoad method. The loaded state was written by the instance in process 1. The instance updates the state in the business method. When the method completes, the container invokes ejbStore . The instance writes the updated state to the database in the ejbStore method.

In the above scenario, the container presents the business methods operating on the entity object Account 100 with a consistent view of the entity object's state within the transaction.

Another implementation of the EJB container might avoid calling ejbLoad and ejbStore on each business method by using a distributed lock manager.

EJB.11.7.3 Bean Provider's Responsibilities

This subsection specifies the bean provider's responsibilities with respect to the diamond case involving an entity object.

The diamond case is transparent to the bean provider ”the bean provider does not have to code the enterprise bean differently for the bean to participate in a diamond. Any solution to the diamond problem implemented by the container is transparent to the bean and does not change the semantics of the bean.

EJB.11.7.4 Application Assembler and Deployer's Responsibilities

This subsection specifies the application assembler and deployer's responsibilities with respect to the diamond case involving an entity object.

The application assembler and deployer should be aware that distributed diamonds might occur. In general, the application assembler should try to avoid creating unnecessary distributed diamonds.

If a distributed diamond is necessary, the deployer should advise the container (using a container-specific API) that an entity object of the entity bean may be involved in distributed diamond scenarios.

EJB.11.7.5 Transaction Diamonds Involving Session Objects

While it is illegal for two clients to access the same session object, it is possible for applications that use session beans to encounter the diamond case. For example, program A starts a transaction and then invokes two different session objects (Figure EJB.11-8).

Figure EJB.11-8. Transaction Diamond Scenario with a Session Bean

If the session bean instances cache the same data item (e.g., the current balance of Account 100) across method invocations in the same transaction, most likely the program is going to produce incorrect results.

The problem may exist regardless of whether the two session objects are the same or different session beans. The problem may exist (and may be harder to discover) if there are intermediate objects between the transaction initiator and the session objects that cache the data.

There are no requirements for the container provider because it is impossible for the container to detect this problem.

The bean provider and application assembler must avoid creating applications that would result in inconsistent caching of data in the same transaction by multiple session objects.