Hibernate caching

Preview:

Citation preview

Hibernate Cache

Alex Verdyan

Why cache?

Why it works?● Temporal locality● Non uniform distribution of hits

Temporal locality

Non-uniform distribution

17,000 pageviews avg load = 250ms

cache 17 pages / 80% of viewscached page load time = 10 msnew avg load = 58ms

● Trade memory for latency reduction

● Reduce database load

Hibernate cache

● Session level cache - L1● SessionFactory (JVM) cache - L2● Query Cache

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

L2 cache - configuration

1. Get ehcache.jar and add it to classpath2.

3. Edit persistence.xml

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

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

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

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

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

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

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)

Query cache

Query cache

What happens if don't query by Id ?

The query cache will look like:*---------------------------------------------------------

-*

| Query Cache

|

|---------------------------------------------------------

-|

| ["from Person as p |

| where p.parent.id=? |

| and p.firstName=?", [1, "Joey"]] -> [2]] |

*---------------------------------------------------------

-*

Query cache

There are 3 cache regions:● StandardQueryCache

○ cached query results

● UpdateTimestampsCache○ holding timestamps of the most recent updates

● NamedQueryCaches ○ Query.setCacheRegion(name)

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 invalidatedThis allows Hibernate to bypass UpdateTimestampCache

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

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

Cache providers

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.)

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

More cache providers

● Hazelcast● GemFire● Oracle Coherence● Gigaspaces

Monitoring

Questions

Recommended