7.3 EJB BMP with JDO

From a JDO perspective, persisting EJBs as part of a bean-managed persistence model has little difference from persisting other kinds of objects. The most common difference is that you tend to be in a managed environment when working with EJBs; similarly, you tend to be in a nonmanaged environment when building other kinds of applications. You can, of course, build web applications in a managed environment and EJB applications that use bean-managed transactions.

One key differentiator between working with JDO in a managed J2EE container versus a nonmanaged environment—besides the obvious impact of transaction management—is the way you reference the PersistenceManagerFactory class. In a non-J2EE container or a nonmanaged environment, you pass a set of properties to the JDOHelper class. The JDOHelper class then hands you the appropriate PersistenceManagerFactory.

When working in a J2EE container, you can rely on JNDI to provide you with a PersistenceManagerFactory without worrying about properties:

Context ctx = new InitialContext( );
PersistenceManagerFactory factory;
   
factory = (PersistenceManagerFactory)ctx.lookup("jdo/pmf");

7.3.1 Transaction Management

Because you are working in an EJB environment, transaction management issues disappear from your radar when using JDO as a bean-managed persistence tool. The exception to this advantage comes when you decide to use bean-managed transactions. Managing your own transactions is one of the pitfalls of working with JDO in a nonmanaged environment. You definitely do not want to introduce that pitfall into this environment unless something makes bean-managed transactions your only option. If you do opt for bean-managed transactions, you should remember that it is a really bad idea to mix bean-managed and container-managed transactions. Chapter 5 has a detailed discussion of this topic.

BEST PRACTICE: Avoid bean-managed transactions unless there is an overriding need for them.

7.3.2 Persistence Strategies

In an EJB application, session beans perform the role we set aside for the Bookshelf class in the previous section. They may also create value objects for the entities that match any queries performed by the session bean. The entity beans, on the other hand, contain the business logic behind any persistent object. Depending on your EJB architecture philosophy, either the entity bean itself or its value object can be the JDO PersistenceCapable class. Using the value object, however, and having the entity bean delegate to the value object for all state information enables you to maintain state information in a single location.

If you take the approach of using the JDO instance as your value object, you need to take care that it is not involved in an uncommitted transaction when you serialize it to the client. Doing so may cause unpredictable exceptional conditions.