The document discusses Hibernate caching at three levels - the first level session cache, query cache, and second level cache - and describes how each cache is structured and functions, focusing on the second level cache and explaining the different cache strategies of read-only, read-write, nonstrict read-write, and transactional.

1. Hibernate caching
2012
Barnabás Südy
barnabas.sudy@gmail.com

2. Structure
Three cache
1st level cache - Session cache
Hibernate 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 cache
Not supported by default (Ehcache)
Stores the entities (dehydrated - not as objects)
1/sessionfactory (entitymanager)

3. Default behavior

Hibernate does not run queries (at all)

Query cache can store the
(Query, List<PrimaryKey>) pairs.

2nd level cache stores the entities.
Questions:

What piece of data should be cached?

Hibernate has to know which piece of
data valid in the cache.

4. Read phenomena

Phantom reads
Other transaction modifies the data

Non Repeatable reads
Other transaction adds new data

Dirty data
Not committed data in the result.

5. Isolation levels
Serializable
--- Phantom reads ---
Repeatable read
--- Non repeatable reads ---
Committed read
--- Dirty data ---
Uncommitted read

6. 2nd level cache
To optimise the performance Hibernate
introduced the Cache strategies:

Read only

Read-Write

NonStrict Read-Write

Transactional

7. 2nd level cache
To optimise the performance Hibernate
introduced the Cache strategies:

Read only

Read-Write

NonStrict Read-Write

Transactional

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

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

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

11. How is works - Read-only

The modification is disabled.

No 2nd level cache update needed.

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

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

14. How it works - Read-write
Let's take a look our test code.

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

16. A little bit configuration....

Persistence.xml

Annotations

Ehcache.xml

Etc.