JCA, JTA, and JDO Transactions

Some JDO implementations are designed to work in unmanaged environments, and some are designed to work in managed environments that use the J2EE Connector Architecture and the Java Transaction API. Some JDO implementations work in both managed and unmanaged environments.

Note

To learn more about JCA and JTA, visit the Sun Microsystems Web site at http://java.sun.com.

One of the purposes of JCA is to define the contracts between a resource adaptor that manages a transactional service and the container that manages transactions. When a JDO implementation is designed to work with a J2EE container, it can function as a resource adaptor within JCA. In this case, the JDO implementation supports all of the connection, transaction, and security contracts that JCA requires. Alternatively, the JDO implementation can function as a caching manager within JCA. In this case, the JDO implementation integrates with the transaction management of JCA and uses some existing resource adaptor to connect to the datastore. Some implementations may be able to perform in either role. Either way, as a result of its integration with JCA and JTA, the J2EE container can control the JDO transactions.

When the J2EE container controls the EJB's transactional boundaries, the container is providing a service called container-managed transactions. The application code in the EJB that uses CMT does not call the boundary methods in the JDO Transaction interface. When the CMT EJB calls a factory to get a persistence manager, the factory method enlists the persistence manager in the container-managed transaction, if there is one. If there isn't an active transaction, then the persistence manager must be used nontransactionally. In other words, the NontransactionalRead property must be turned on and persistent state cannot be updated.

Note

Chapter 6 provides code templates for most types of EJB components, and describes in detail how and when to obtain a persistence manager inside an EJB.

J2EE allows session beans to manage their own transactions. This capability is called bean-managed transactions. Only session beans have the BMT option. The application code in a BMT session bean has the option of using the JDO Transaction interface or the JTA javax.transaction.UserTransaction interface to control the transactional boundaries. The use of the UserTransaction interface imposes some constraints that must be observed.

In a BMT session bean, the UserTransaction is obtained from the javax.ejb.SessionContext interface. When the bean uses UserTransaction to start the transaction, the PersistenceManager object must be obtained from the PersistenceManagerFactory after the transaction is started; otherwise, the persistence manager is not enlisted in the transaction. As a result, if the application wanted to execute two transactions, one after the other, within a bean method, it must obtain one persistence manager for each transaction that it starts with the UserTransaction interface.

When the application uses the JDO Transaction interface, it has more flexibility. In a BMT session bean, the JDO Transaction interface can control the transaction just as it can in an unmanaged environment. In this case, the application code does not use the UserTransaction interface at all. If the application wants to run a series of transactions, the same persistence manager may be used. The JDO implementation, if it is designed to work with JCA and JTA, ensures that the UserTransaction begins when the JDO Transaction begins and completes when the JDO Transaction completes. For simplicity, it is recommended that the application code always use the JDO Transaction interface in BMT session beans.