Sun Microsystems Inc.

The EJB specification does not prescribe how the Container should manage the execution of a method with an unspecified transaction context—the transaction semantics are left to the Container implementation. Some techniques for how the Container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):

•The Container may execute the method and access the underlying resource managers without a transaction context.

•The Container may treat each call of an instance to a resource manager as a single transaction (e.g. the Container may set the auto-commit option on a JDBC API connection).

•The Container may merge multiple calls of an instance to a resource manager into a single transaction.

•The Container may merge multiple calls of an instance to multiple resource managers into a single transaction.

•If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the Container may merge the resource manager calls from the multiple instances into a single transaction.

•Any combination of the above.

Since the enterprise bean does not know which technique the Container implements, the enterprise bean must be written conservatively not to rely on any particular Container behavior.

A failure that occurs in the middle of the execution of a method that runs with an unspecified transaction context may leave the resource managers accessed from the method in an unpredictable state. The EJB architecture does not define how the application should recover the resource managers’ state after such a failure.

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.

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.

Sun Microsystem Inc

Figure 46 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[13].

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.

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

Sun Microsystems Inc.

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 follows. The illustration is illustrative, not prescriptive for the Container implementors.

Sun Microsystem Inc

Figure 47 Handling of diamonds by a multi-process container

Multi-process EJB Container

process 1

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.

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.