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?
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
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 orjavax.persistence.sharedCache.mode
in properties
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
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.
© 2022 - 2024 — McMap. All rights reserved.