Java Reference
In-Depth Information
There is little to tune within an entity manager transaction cache (the L1 cache), and the L1
cache is enabled in all JPA implementations. The L2 cache is different: most JPA implement-
ations provide one, but not all of them enable it by default (e.g., Hibernate does not, but
EclipseLink does). Once enabled, the way in which the L2 cache is tuned and used can sub-
stantially affect performance.
The JPA cache operates only on entities accessed by their primary keys; that is, items re-
trieved from a call to the find() method, or items retrieved from accessing (or eagerly load-
ing) a related entity. When the entity manager attempts to find an object via either its primary
key or a relationship mapping, it can look in the L2 cache and return the object(s) if they are
found there, thus saving a trip to the database.
Items retrieved via a query are not held in the L2 cache. Some JPA implementations do have
a vendor-specific mechanism to cache the results of a query, but those results are only reused
if the exact same query is re-executed. Even if the JPA implementation supports query cach-
ing, the entities themselves are not stored in the L2 cache and cannot be returned in a subse-
quent call to the find() method.
There are many ways that the connections between the L2 cache, queries, and the loading of
objects affects performance. To examine them, code based on the following loop will be
used:
EntityManager em = emf . createEntityManager ();
Query q = em . createNamedQuery ( queryName );
List < StockPrice > l = q . getResultList ();
for
for ( StockPrice sp : l ) {
... process sp ...
iif ( processOptions ) {
Collection <? extends
extends StockOptionPrice > options = sp . getOptions ();
for
for ( StockOptionPrice sop : options ) {
... process sop ...
}
}
}
em . close ();
SQL Call Site 1
SQ L Call Site 2
 
 
Search WWH ::




Custom Search