ORM and distributed caching
- 1. ORM and Distributed Caching Alexey Ragozin [email protected] 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