Hibernate caching
2 likes3,142 views
Hibernate provides two levels of caching: a session-level cache (L1) and a session factory-level cache (L2). The L1 cache is enabled by default and caches objects retrieved and saved during a session. The L2 cache caches objects across sessions and can improve performance by reducing database load. It is configurable and can be clustered. Hibernate also supports a query cache that caches query results, but it requires careful configuration to avoid issues from invalidated data.
![How will the cache look like
*-----------------------------------------------------*
| Person Data Cache |
|-----------------------------------------------------|
| 1 -> [ "John" , "Bon Jovi" , null , [ 2 , 3 ] ] |
| 2 -> [ "Joey" , "Ramone" , 1 , [] ] |
| 3 -> [ "Sara" , "Connor" , 1 , [] ] |
*-----------------------------------------------------*
Hibernate cache stores
"dehydrated" objects](https://image.slidesharecdn.com/hibernatecaching1-130703022513-phpapp01/85/Hibernate-caching-14-320.jpg)
Hibernate caching
- 2. Why cache? Why it works? ● Temporal locality ● Non uniform distribution of hits
- 5. 17,000 pageviews avg load = 250ms cache 17 pages / 80% of views cached page load time = 10 ms new avg load = 58ms ● Trade memory for latency reduction ● Reduce database load
- 6. Hibernate cache ● Session level cache - L1 ● SessionFactory (JVM) cache - L2 ● Query Cache
- 7. Session cache - L1 ● Enabled by default ● Used transparently during the session ● All objects that was saved or retrieved ○ save ○ update ○ get ○ list ○ iterate ● flush() - will sync cache to DB ● clear() - will evict all objects
- 8. L2 cache - configuration 1. Get ehcache.jar and add it to classpath 2. 3. Edit persistence.xml
- 9. L2 Cache ● Inter-session cache ● Can be clustered ● Configurable with XML or Annotations ● Divided to regions ○ Entity - data ○ Collections - relations ○ Queries - query results ○ Timestamps - last update timestamp for tables
- 10. L2 cache strategies ● Read-only ○ simplest, safest and fastest ○ supports insert, no update/delete ○ ● Nonstrict Read-Write ○ occasional writes, no locking cache ○ low prob. that 2 transactions will write the same object ○ async - update
- 11. L2 cache strategies ● Read-Write ○ read committed - transaction isolation ○ uses soft locks ○ async - cache update out of tx ● Transactional ○ only with JTA (i.e. with distributed tx support) ○ serialized transaction isolation ○ sync - cache update inside tx
- 12. L2 cache - how it works ● Does not cache actual objects ● Caches values of the properties ● Mappings (relations) are not cached by default ○ it can helps with N+1 queries
- 13. Example ● cache of the mapping is optional ● although it's the best place to improve ● beware of code altering the associations and not cascading the change
- 14. How will the cache look like *-----------------------------------------------------* | Person Data Cache | |-----------------------------------------------------| | 1 -> [ "John" , "Bon Jovi" , null , [ 2 , 3 ] ] | | 2 -> [ "Joey" , "Ramone" , 1 , [] ] | | 3 -> [ "Sara" , "Connor" , 1 , [] ] | *-----------------------------------------------------* Hibernate cache stores "dehydrated" objects
- 15. Evicting from cache From L1 cache (Session) session.evict(entity) session.evict(Person.class) From L2 cache (SessionFactory) sf.getCache().evictEntity(Person.class,2L); sf.getCache(). evictCollection("com.bla.Person.children",1L)
- 16. Query cache
- 17. Query cache What happens if don't query by Id ? The query cache will look like: *--------------------------------------------------------- -* | Query Cache | |--------------------------------------------------------- -| | ["from Person as p |
- 18. Query cache There are 3 cache regions: ● StandardQueryCache ○ cached query results ● UpdateTimestampsCache ○ holding timestamps of the most recent updates ● NamedQueryCaches ○ Query.setCacheRegion(name)
- 19. Query Cache QC is useful when you query by "Natural id" Criteria crit = session.createCriteria(Person.class); crit.add( Restrictions. naturalId(). set("email", "joey@ramones.com")). setCacheable(true). uniqueResult(); Since Natural Id immutable, Natural Id -> Primary Key mapping cannot be invalidated This allows Hibernate to bypass UpdateTimestampCache
- 20. Query Cache - Pitfalls ● Any update to the underlying table updates the timestamp cache - invalidates all entities ● Memory ○ the queries are large pretty strings and the bind variables can be objects ● Lock contention - QC has a coarse lock on timestamp cache for insert/update/delete and lookups
- 21. Stuff to remember ● Cache cannot know about updates made to the persistent store by another application ● Query cache - unless you use a natural key is almost always a bad idea ○ unless you know what you're turning it on ○ you can show an improvement with realistic load ● TTL and TTI ○ tune them
- 22. Cache providers
- 23. Bundled cache providers Cache Type Cluster Safe Query Cache Supported ConcurrentHashMap memory no yes EHCache memory, disk, transactional, clustered yes yes Infinispan (JBoss Cache) clustered (ip multicast), transactional yes yes (clock sync req.)
- 24. Bundled cache providers Cache read-only nonstrict-read-write read-write transactional ConcurrentHashMap yes yes yes EHCache yes yes yes yes Infinispan (JBoss cache) yes yes
- 25. More cache providers ● Hazelcast ● GemFire ● Oracle Coherence ● Gigaspaces
- 26. Monitoring
- 27. Questions