Hibernate caching
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,865
On Slideshare
1,861
From Embeds
4
Number of Embeds
2

Actions

Shares
Downloads
35
Comments
0
Likes
1

Embeds 4

http://www.linkedin.com 3
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Hibernate Cache Alex Verdyan
  • 2. Why cache? Why it works? ● Temporal locality ● Non uniform distribution of hits
  • 3. Temporal locality
  • 4. Non-uniform distribution
  • 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
  • 28. References http://tech.puredanger.com/2009/07/10/hibernate- query-cache/ http://anirbanchowdhury.wordpress. com/2012/07/23/hibernate-second-level-cache- ehcache/#introduction http://www.javalobby.org/java/forums/t48846.html http://www.slideshare.net/alexmiller/cold-hard-cache