Structure

Three cache

1st level cache - Session cacheHibernate supported cache.

Ensures the entities are returnd always on the same reference

1/session (entitymanager) - Not thread safe

Query cache

Not supported by default. (Ehcache)

Stores the queries and their results.

1/sessionfacory (entitymanagerfactory)

2nd level cacheNot supported by default (Ehcache)

Stores the entities (dehydrated - not as objects)

1/sessionfactory (entitymanager)

Default behavior

Questions: What piece of data should be cached? Hibernate has to know which piece of

data valid in the cache.

Hibernate does not run queries (at all) Query cache can store the

(Query, List<PrimaryKey>) pairs. 2nd level cache stores the entities.

Read phenomena

Phantom readsOther transaction modifies the data

Non Repeatable readsOther transaction adds new data

Dirty dataNot committed data in the result.

Isolation levels

Serializable

--- Phantom reads ---

Repeatable read

--- Non repeatable reads ---

Committed read

--- Dirty data ---

Uncommitted read

2nd level cache

To optimise the performance Hibernate introduced the Cache strategies:

Read only Read-Write NonStrict Read-Write Transactional

2nd level cache

To optimise the performance Hibernate introduced the Cache strategies:

Read only Read-Write NonStrict Read-Write Transactional

Read only strategy

A read-only cache is good for data that needs to be read often but not modified.

Simple Safe to use in a clustered environment. The data has to never ever modify. Best performance.

NonStrict Read-Write

Rarely need to modify data. This is the case if two transactions are unlikely to try to update the

same item simultaneously.

No strict transaction isolation Ensure Session.close() or

Session.disconnect() is called at the end of transaction. (except JTA)

hibernate.transaction.manager_lookup_class to use in JTA environment.

Read-Write

Appropriate for an application which needs to update data regularly. (not exacly true)

Do not use a if serializable isolation needed.

Ensure Session.close() or Session.disconnect() is called at the end of transaction. (except JTA)

hibernate.transaction.manager_lookup_class to use in JTA environment.

How is works - Read-only

The modification is disabled. No 2nd level cache update needed.

How is works - NonStrict Read-Write

The entities are evicted from the 2nd level cache by their life timeout. Until the eviction they are in use.

Repeatable reads problem is not solved. The queries are not forwarded to the database.

How it works - Read-write

Transaction and entity timestamp. If transaction timestamp is older than the

entity timestamp the entity has to be pulled out from the database.

The responsibility is deflected to the database.

How it works - Read-write

Let's take a look our test code.

Good to know

Be careful with query cache without 2nd level cache.

Be careful 2nd level cache without query cache.

Be careful query cache and read-write entity.

And again: 2nd level cache is not queryable only findable.

The first level cache keeps the entity references.

A little bit configuration....

Persistence.xml Annotations Ehcache.xml Etc.