4. Second level cache
Query cache
Query -> Result set (list of entry references)
Entity cache
PK (entry reference) -> Entity data
Makes query cache useful
Helps with “N+1 select” problem
Actively used for lazy loading of entities
5. Consistency problem
Stale data in entity cache = big problem
Single process application
Locking, to prevent concurrent updates
Write through – modify DB and cache together
Distributed application
1. JTA transaction manager (add cache to Tx)
2. Use distributed locks for concurrency control
6. Solving Query Problem
Caching queries
Exact query match may be infrequent
Invalidation is messy
Why not execute quires in cache?
Execute query in entity cache
No invalidation problem
Coherence, GemFire, Hazelcast has index support
7. Queries in Entity Cache
Pro
DB is not involved in query processing
Fallback to DB for complex quries
Still using old good (or bad) JPQL
Cons
ALL entities should be loaded in cache
Only simple selects, no join queries are supported
though link traversing works as usual
8. What is Next?
Coherence cache is durable
Why update DB synchronously?
Write behind for ORM
PRO
reducing transaction execution time
removing DB from critical path
CON
Coherence does not honor transaction boundaries
DB is out of sync, no way for execution complex JPQL
9. Few More Interesting Stuff
Works with TopLink Grid
Real transaction support
Durability via distributed disk log
HIBERNATE OGM
JPQL for NoSQL (data grid included)
Lucene (Hibernate Search) support