Difference between Container-managed and Application - managed EntityManager

[Padma Priya]

Hi all,

In the Chapter 5 of JPA spec it says

In less common use cases within Java EE environments, applications may need to access a persistence context that is “stand-alone”—i.e. not propagated along with the JTA transaction across the EntityManager references for the given persistence unit. Instead, each instance of creating an entity manager causes a new isolated persistence context to be created that is not accessible through other EntityManager references within the same transaction. These use cases are supported through the createEntityManager methods of the EntityManagerFactory interface. An entity manager that is used by the application to create and destroy a persistence context in this manner is termed an application-managed entity manager. An application-managed entity manager’s lifecycle is managed by the application.

and it also says

When an application-managed entity manager is used, the application interacts directly with the persistence provider's entity manager factory to manage the entity manager lifecycle and to obtain and destroy persistence contexts. All such application-managed persistence contexts are extended in scope, and may span multiple transactions.

I am a bit confused. At one place it says persistence contexts are stand alone and another it says presistence contexts are extended.
Can anybody explain?

Thanks in advance

With regards
Deepthi.

[ryan sukale]

Hi Deepthi,

A persistence context is somwhat like a logical collection of managed entities in the memory.
When you create an application-managed persistence context, for a given persistence unit, you are specifying the entitiy types that the persistence context will manage.

Now, when an application managed entity manager is associated with a transaction, it is bound to get in sync with the database when the transaction commits., ie, all the changes made to the entities that had become managed during the scope of the transaction using that entity manager will be saved in the database at transaction commit time. Once the transaction commits, the 'in-memory' entities are not cleared. They will still be tracked down by the entity manager in the case of an application-scoped entity manager. So, if you make changes to the managed entities when there is no transaction surrounding the entity manager, then entity manager will keep track of them.

The next time your app-managed entity manager becomes associated with a transaction, the chages will be reflected in the database when the transaction commits or a flush is done, as implemented by your persistence provider.

This indicates that your persistence context has an 'extended' lifespan, because even in the absence of a transaction, the entity instances remain managed. So the 'standalone' feature refers to the fact that persistence context 'propagation' i.e, using the same persistence context for utility method that you call from you method that creates the entity manager, is not inherently available for a app-managed entity manager but which is available in the case of a container-managed entity manager. The container handles the propagation for you behind the scenes.

In the case of a container-managed entity manager, all the entity that were managed during the transaction become detached the moment the transaction commits. So, changes made outside the transaction will not be reflected. These changes can be updated in your DB only when you try to again make these detached instances managed by the merge method.

Hope this helps

Regards
Ryan Sukale

[Padma Priya]

Thanks a lot Ryan for clearing my doubt with your detailed explanation.