JPA 2.1: Unsynchronized persistence context

Martin MoisMarch 5th, 2015Last Updated: March 3rd, 2015

1 119 3 minutes read

The JPA version 2.1 brings a new way how to handle the synchronization between the persistence context and the current JTA transaction as well as the resource manager. The term resource manager comes from the Java Transaction API and denotes a component that manipulates one resource (for example a concrete database that is manipulated by using its JDBC driver). Per default a container-managed persistence context is of type SynchronizationType.SYNCHRONIZED, i.e. this persistence context automatically joins the current JTA transaction and updates to the persistence context are propagated to the underlying resource manager.

By creating a persistence context that is of the new type SynchronizationType.UNSYNCHRONIZED, the automatic join of the transaction as well as the propgation of updates to the resource manager is disabled. In order to join the current JTA transaction the code has to call the method joinTransaction() of the EntityManager. This way the EntityManager’s persistence context gets enlisted in the transaction and is registered for subsequent notifications. Once the transaction is commited or rolled back, the persistence context leaves the transaction and is not attached to any further transaction until the method joinTransaction() is called once again for a new JTA transaction.

Before JPA 2.1 one could implement a conversation that spans multiple method calls with a @Stateful session bean as described by Adam Bien here:

@Stateful
@TransactionAttribute(TransactionAttributeType.NEVER)
public class Controller {
    @PersistenceContext(type = PersistenceContextType.EXTENDED)
    EntityManager entityManager;
 
    public Person persist() {
        Person p = new Person();
        p.setFirstName("Martin");
        p.setLastName("Developer");
        return entityManager.merge(p);
    }
 
    public List<Person> list() {
        return entityManager.createQuery("from Person", Person.class).getResultList();
    }
 
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void commit() {
         
    }
 
    @Remove
    public void remove() {
 
    }
}

The persistence context is of type EXTENDED and therefore lives longer than the JTA transactions it is attached to. As the persistence context is per default also of type SYNCHRONIZED it will automatically join any transaction that is running when any of the session bean’s methods are called. In order to prevent that to happen for most of the bean’s methods, the annotation @TransactionAttribute(TransactionAttributeType.NEVER) tells the container to not open any transaction for this bean. Therefore the methods persist() and list() run without a transaction. This behavior is different for the method commit(). Here the annotation @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) tells the container to create a new transaction before the method is called and therefore the bean’s EntityManager will join it automatically.

With the new type SynchronizationType.UNSYNCHRONIZED the code above can be rewritten as depicted in the following listing:

@Stateful
public class Controller {
    @PersistenceContext(type = PersistenceContextType.EXTENDED,
        synchronization = SynchronizationType.UNSYNCHRONIZED)
    EntityManager entityManager;
 
    public Person persist() {
        Person p = new Person();
        p.setFirstName("Martin");
        p.setLastName("Developer");
        return entityManager.merge(p);
    }
 
    public List<Person> list() {
        return entityManager.createQuery("from Person", Person.class).getResultList();
    }
 
    public void commit() {
        entityManager.joinTransaction();
    }
 
    @Remove
    public void remove() {
 
    }
}

Now that the EntityManager won’t automatically join the current transaction, we can omit the @TransactionAttribute annotations. Any running transaction won’t have an impact on the EntityManager until we explicitly join it. This is now done in the method commit() and could even be done on the base on some dynamic logic.

In order to test the implementation above, we utilize a simple REST resource:

@Path("rest")
@Produces("text/json")
@SessionScoped
public class RestResource implements Serializable {
    @Inject
    private Controller controller;
 
    @GET
    @Path("persist")
    public Person persist(@Context HttpServletRequest request) {
        return controller.persist();
    }
 
    @GET
    @Path("list")
    public List<Person> list() {
        return controller.list();
    }
 
    @GET
    @Path("commit")
    public void commit() {
        controller.commit();
    }
 
    @PreDestroy
    public void preDestroy() {
 
    }
}

This resource provides methods to persist a person, list all persisted person and to commit the current changes. As we are going to use a stateful session bean, we annotate the resource with @SessionScoped and let the container inject the Controller bean.

By calling the following URL after the application has been deployed to some Java EE container, a new person gets added to the unsynchronized persistence context, but is not stored in the database.

http://localhost:8080/jpa2.1-unsychronized-pc/rest/persist

Even a call of the list() method won’t return the newly added person. Only by finally synchronizing the changes in the persistence context to the underlying resource with a call of commit(), the insert statement is send to the underlying database.

Conclusion

The new UNSYNCHRONIZED mode of the persistence context lets us implement conversations over more than one method invocation of a stateful session bean with the flexibility to join a JTA transaction dynamically based on our application logic without the need of any annotation magic.