9.6. Summary
We've covered a lot of ground in this chapter. You now know that the basic interfaces in Java Persistence aren't much different from those provided by Hibernate. Loading and storing objects is almost the same. The scope of the persistence context is slightly different, though; in Hibernate, it's by default the same as the Session scope. In Java Persistence, the scope of the persistence context varies, depending on whether you create an EntityManager yourself, or you let the container manage and bind it to the current transaction scope in an EJB component.
Table 9.1 shows a summary you can use to compare native Hibernate features and Java Persistence.
| Hibernate Core | Java Persistence and EJB 3.0 |
|---|---|
| Hibernate defines and relies on four object states: transient, persistent, removed, and detached. | Equivalent object states are standardized and defined in EJB 3.0. |
| Detached objects can be reattached to a new persistence context or merged onto persistent instances. | Only merging is supported with the Java Persistence management interfaces. |
| At flush-time, the save() and update() operations can be cascaded to all associated and reachable instances. The persist() operation can only be cascaded to reachable instances at call-time. | At flush-time, the persist() operation can be cascaded to all associated and reachable instances. If you fall back to the Session API, save() and update() are only cascaded to reachable instances at call-time. |
| A get() hits the database; a load() may return a proxy. | A find() hits the database; a getReference() may return a proxy. |
| Dependency injection of a Session in an EJB works only in JBoss Application Server. | Dependency injection of an EntityManager works in all EJB 3.0 components. |
We've already talked about conversations in an application and how you can design them with detached objects or with an extended persistence context. Although we haven't had time to discuss every detail, you can probably already see that working with detached objects requires discipline (outside of the guaranteed scope of object identity) and manual reattachment or merging. In practice, and from our experience over the years, we recommend that you consider detached objects a secondary option and that you first look at an implementation of conversations with an extended persistence context.
Unfortunately, we still don't have all the pieces to write a really sophisticated application with conversations. You may especially miss more information about transactions. The next chapter covers transaction concepts and interfaces.