Editor's note: In last week's excerpt from Chapter 7 of Java Database Best Practices, author George Reese covered basic JDO persistence best practices for transaction management and query control. In this week's concluding excerpt on JDO persistence, George covers using JDO as a bean-managed persistence tool.
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
class then hands you the appropriate
When working in a J2EE container, you can rely on JNDI to provide you with a
PersistenceManagerFactory without worrying about
Context ctx = new InitialContext( ); PersistenceManagerFactory factory; factory = (PersistenceManagerFactory)ctx.lookup("jdo/pmf");
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.
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.
George Reese is the founder of two Minneapolis-based companies, enStratus Networks LLC (maker of high-end cloud infrastructure management tools) and Valtira LLC (maker of the Valtira Online Marketing Platform). He is also the author of technology books such as the MySQL Pocket Reference, Database Programming with JDBC and Java, and Java Database Best Practices.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.