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