Slides from meet up in Moscow, 2012 May 17

1. ORM and Distributed Caching
Alexey Ragozin
alexey.ragozin@gmail.com
May 2012

2. ORM cache hierarchy
Session
Level 1
Query cache Entry cache
Level 2
Database

3. ORM cache hierarchy
Session
POJO
Level 1
Query cache Entry cache
Sets of PK Entities
Level 2
Database

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

10. Thank you
http://aragozin.blogspot.com
Alexey Ragozin
alexey.ragozin@gmail.com