JDO s Support for Container-Managed Transactions

JDO's Support for Container-Managed Transactions

The sophisticated management of transactions is a major feature of J2EE application servers. The application server may manage a local transaction involving only one transactional service, or it may manage a distributed transaction involving several services. The application server can either continue using an existing active transaction or start a new transaction. In the case of EJBs, the server provides container-managed transactions (CMT) and allows bean-managed transactions (BMT).

The EJB container in the application server supports several deployment options for CMT. Session beans can use any of six transactional attributes (Unsupported, Required, RequiresNew, Supported, Mandatory, and Never) for container-managed transactions, while entity beans and message-driven beans can use a subset of these.

When using CMT, the bean code does not set transactional boundaries. The transactional boundaries are controlled by the originator of the managed transaction. Depending on the transactional attribute, the application server may start a managed transaction before calling the bean's business method, or it may call the bean's business method in the context of an existing transaction, or it may call the bean's business method in a nontransactional context.

When the bean code calls the ConnectionFactory or PersistenceManagerFactory interface for a persistence manager, the factory has the opportunity to enlist the persistence manager in the active managed transaction, if there is one. Enlisting the persistence manager simply means that the Active property of the persistence manager's transaction is now true, and the JDO transaction is now under the control of the originator of the managed transaction. As a result, when the factory enlists the persistence manager in the managed transaction, the JDO transaction is active when the persistence manager is returned.

Note

There is one JDO Transaction object associated with every PersistenceManager object. Often they are the same object.

JDO allows, but does not require, support for managed transactions in the implementation of the PersistenceManagerFactory interface. On the other hand, JCA requires support for managed transactions in the implementation of the ConnectionFactory interface. Support for managed transactions is often a key difference between the "enterprise" version of a JDO implementation and a "standard" version from the same vendor.

For some of the six possible transactional attributes for CMT, the EJB container can invoke the bean's business methods in a nontransactional context, that is to say, without an active managed transaction. As a result, the persistence manager is not enlisted and its transaction is not started. Because the bean should not start a transaction when the container is managing transactions, the bean must use JDO nontransactionally. When the container calls the bean in a nontransactional context, the NontransactionalRead property should be turned on to allow read access. Assuming that the JDO implementation supports nontransactional reads, the bean code can turn on the NontransactionalRead property in the Transaction interface after the persistence manager is obtained. Turning on the property in the code is not necessary when the factory is deployed with the NontransactionalRead property set to true. Although the bean code can use JDO to read persistent objects in a nontransactional context when the NontransactionalRead property is true, without an active managed transaction, the CMT bean cannot use JDO to update the datastore.

In summary, there are two points to remember when using JDO with container-managed transactions. One, a persistence manager is enlisted in the managed transaction only at the time that the connection factory or persistence manager factory returns it. There is no other enlistment mechanism available to the JDO implementation. If an EJB with CMT caches a persistence manager from one transaction to the next, JDO does not have the opportunity to enlist the persistence manager in the second managed transaction. Two, if the CMT deployment descriptor allows the container to invoke the bean in a nontransactional context, then the bean code should not start a transaction. Instead, it should use JDO nontransactionally.