Is there a stateless version of the JPA EntityManager?

Question

Hibernate has a Stateless Version of its Session: Does something similar exist for the JPA EntityManager? I.e. an EntityManager that does not use the first level cache?

Answer 1

From JPA point of view:

• javax.persistence.EntityManager stands for 1st level cache (persistence context, transactional cache)
• javax.persistence.EntityManagerFactory stands for 2nd level cache (shared cache)

A given persistence provider may implement additional caching layers. Additionally JDBC Driver API may be treated as low-level cache for storing columns/tables and caching connections/statements. It's however transparent to JPA.

Both javax.persistence.EntityManager and org.hibernate.StatelessSession offer similar APIs.

You cannot disable 1st level cache with EntityManager beacuse these two things are equivalent. You can however:

• skip 1st level cache by using createQuery, createNamedQuery, createNativeQuery for querying and bulk updates/deletes (the persistence context is not updated to reflect their results). Such queries should be executed in their own transaction thus invalidating any cached entities, if any. Transaction-scoped entity manager (means stateless) should be used as well.
• disable 2nd level cache by setting up <shared-cache-mode>NONE</shared-cache-mode> in persistence.xml or javax.persistence.sharedCache.mode in properties

Answer 2

Not part of the JPA API or spec. Individual implementations may allow disabling the L1 cache. DataNucleus JPA, the one I have used, does allow this

Answer 3

On an interface point of view, RDBMS usually respect the ACID constraints, a stateless option would be very specific. I guess this is the reason why Hibernate proposes this feature but not the specification.

To disable the cache, you have implementation-specific configurations (here is the doc for EclipseLink). The @Cacheable annotation (JPA 2.0) at the entity level is standard.

But if you would like to perform bulk operations, this would not do the job. Anyway, such a behavior would be implementation-specific.