What is the difference between Transaction-scoped Persistence context and Extended Persistence context?

The difference is clearly explained in the JSR-220 Enterprise JavaBeans 3.0 specification:

5.6 Container-managed Persistence Contexts

(...)

A container-managed persistence context may be defined to have either a lifetime that is scoped to a single transaction or an extended lifetime that spans multiple transactions, depending on the PersistenceContextType that is specified when its EntityManager is created. This specification refers to such persistence contexts as transaction-scoped persistence contexts and extended persistence contexts respectively.

(...)

5.6.1 Container-managed Transaction-scoped Persistence Context

The application may obtain a container-managed entity manager with transaction-scoped persistence context bound to the JTA transaction by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.

A new persistence context begins when the container-managed entity manager is invoked[36] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction.

The persistence context ends when the associated JTA transaction commits or rolls back, and all entities that were managed by the EntityManager become detached.

If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will immediately become detached at the end of the method call.

5.6.2 Container-managed Extended Persistence Context

A container-managed extended persistence context can only be initiated within the scope of a stateful session bean. It exists from the point at which the stateful session bean that declares a dependency on an entity manager of type PersistenceContextType.EXTENDED is created, and is said to be bound to the stateful session bean. The dependency on the extended persistence context is declared by means of the PersistenceContext annotation or persistence-context-ref deployment descriptor element.

The persistence context is closed by the container when the @Remove method of the stateful session bean completes (or the stateful session bean instance is otherwise destroyed).

(...)


There are lot of details to respect... but to keep it short I remember the difference like this:

Transaction-Scoped Persistence Context

In short: When a method on a transaction-scoped bean is called, a transaction will automatically be started by the container and a new persistence context will be created for you. When the method ends the transactions ends and the persistence context will be closed, your entities will become detached.

Benefit: This behaviour is stateless, doesn't need much maintenance in the code by you and makes your EntityManager threadsafe.

Extended Persistence Context

In short: Can be used for a stateful session bean only and is tied to the lifecycle of the bean. The persistence context can spawn accross multiple transactions, which means the methods in your extended bean share the same persistence context.

Benefit: Perfect to implement a conversation style interaction with clients. Your client call several bean methods to tell your bean all the information you need to know and at the end of the conversation you persist everything to your DB.

Important things to know

Transaction propagation: Assuming default TransactionAttributes for a transaction-scoped bean with two methods A and B.

If method B is called inside of method A, you can propagate A's persistence context to B. That way method B can access even non yet persisted entities that where created/changed by A, because they are still managed by the persistence context on which B has now access on.

Transaction propagation from extended to transaction-scoped: You can propagate the persistence context of an extended bean to a transaction-scoped bean by calling a method of your transaction-scoped bean from your extended bean. With default transaction attribute (REQUIRED) your transaction-scoped bean will re-use the already existing, active persistence context of your extended bean.

Transaction propagation from transaction-scoped to extended: The other way around however is not as intuitive, because an extended persistence context always tries to make itself the active persistence context. You have to change the default transaction attribute for the extended bean using @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This will suspend any active transaction (associated with a persistence context) before the extended bean method starts.


Transaction scoped persistence context

As the name suggests, a transaction-scoped persistence context is tied to the lifecycle of the transaction. It is created by the container during a transaction and will be closed when the transaction completes.

Transaction-scoped entity managers are responsible for creating transaction-scoped persistence contexts automatically when needed. We say only when needed because transactionscoped persistence context creation is lazy.

An entity manager will create a persistence context only when a method is invoked on the entity manager and when there is no persistence context available.

Extended Persistence Contexts

The lifecycle of an extended persistence context is tied to the stateful session bean to which it is bound.

Unlike a transaction-scoped entity manager that creates a new persistence context for each transaction, the extended entity manager of a stateful session bean always uses the same persistence context.

The stateful session bean is associated with a single extended persistence context that is created when the bean instance is created and closed when the bean instance is removed. This has implications for both the association and propagation characteristics of the extended persistence context.

Tags:

Java

Jpa