Question

There appear to be two patterns to implement business transactions that span several http requests with JPA:

1. entity-manager-per-request with detached entities
2. extended persistence context

What are the respective advantages of these patterns? When should which be preferred?

So far, I came up with:

• an extended persistence context guarantees that object identity is equivalent to database identity, simplifying the programming model and potentially disspelling the need to implement equals for entities
• detached entities require less memory than an extended persistence context, as the persistence context also has to store the previous state of the entity for change detection
• no longer referenced detached entities become eligible for garbage collection; persistent objects must first be detached explicitly

However, not having any practical experience with JPA I am sure I have missed something of importance, hence this question.

In case it matters: We intend to use JPA 2.0 backed by Hibernate 3.6.

Edit: Our view technology is JSF 2.0, in an EJB 3.1 container, with CDI and possibly Seam 3.

Answer 1

Well, I can enumerate challenges with trying to use extended persistence contexts in a web environment. Some things also depend on what your view technology is and if it’s binding entities or view level middlemen.

1. EntityManagers are not threadsafe.
   You don’t need one per user session.
   You need one per user session per
   browser tab.
2. When an exception comes out of an
   EntityManager, it is considered
   invalid and needs to be closed and
   replaced. If you’re planning to
   write your own framework extensions
   for managing the extended lifecycle,
   the implementation of this needs to
   be bullet proof. Generally in an
   EM-per-request setup the exception
   goes to some kind of error page and
   then loading the next page creates a
   new one anyway like it always would
   have.
3. Object equality is not going to be
   100% automagically safe. As above,
   an exception may have invalidated
   the context an object loaded earlier
   was associated with, so one fetched
   now will not be equal. Making that
   assumption also assumes an extremely
   high level of skill and
   understanding of how JPA works and
   what the EM does among the
   developers using it. e.g.,
   accidentally using merge when it
   wasn’t needed will return a new
   object which will not satisfy ==
   with its field-identical
   predecessor. (treating merge like a
   SQL ‘update’ is an extremely common
   JPA noobie ‘error’ particularly
   because it’s just a no-op most of
   the time so it slides past.)
4. If you’re using a view technology
   that binds POJOs (e.g., SpringMVC)
   and you’re planning to bind web form
   data directly onto your Entities,
   you’ll get in trouble quick.
   Changes to an attached entity will
   become persistent on the next
   flush/commit, regardless of whether
   they were done in a transaction or
   not. Common error is, web form
   comes in and binds some invalid data
   onto an entity, validation fails and
   trys to return a screen to inform
   user. Building error screen
   involves running a query. Query
   triggers flush/commit of persistence
   context. Changes bound to attached
   entity get flushed to database,
   hopefully causing SQL exception, but
   maybe just persisting corrupt data.

(Problem 4 can of course also happen with session per request if the programming is sloppy, but you’re not forced to actively work hard at avoiding it.)