LESSONS FROM THE OCEAN
Speaking of second level cache, it directly comes in
use- indicates a caching strategy: transactional, read-write, nonstrict-read-write or read-only
In terms of object caches, expected call sequences for Create / Update / Delete operations:
DELETES:
lock(java.lang.Object, java.lang.Object) evict(java.lang.Object) release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)
UPDATES:
lock(java.lang.Object, java.lang.Object) update(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object) afterUpdate(java.lang.Object, java.lang.Object, java.lang.Object,org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)
INSERTS:
insert(java.lang.Object, java.lang.Object, java.lang.Object) afterInsert(java.lang.Object, java.lang.Object, java.lang.Object)
In terms of collection caches, all modification actions are simply not valid for entries. The order of calls is here:
lock(java.lang.Object, java.lang.Object) evict(java.lang.Object) release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)
Nonstrict-R / w and R / W cache
Whenever a session starts, a time stamp (ST) is added to it. Whenever an item is loaded into the cache, a time stamp (CT) is added to it Now, if ST <CT, that is, the session is older than the cached item, then if we looking for a cached item in this older session, Hibernate will NOT look in the cache. Instead, it will always look in the database and therefore reload the item in the cache with a fresh timestamp.
For NonStrict-Read-Write
• You do not have a lock.
• So, when the object is actually updated in the database, at the time of commit (until the database completes the commit), the cache has an old object, the database has a new object.
• Now, if any other session is looking for an object, it will search the cache and find the old object. ( DIRTY READ )
• However, as soon as the commit is completed, the object will be removed from the cache, so the next session that searches for the object will have to look in the database.
Read-write
• As soon as someone tries to update / delete an item, the item is locked in the cache, so if any other session tries to find it, it must go to the database.
• Now, as soon as the update is completed and the data has been committed, the cache is updated with fresh data and the lock is released, so that other transactions can now be viewed in CACHE and should not go to the database.
• Thus, it is not possible to use Dirty Read, and any session will ALWAYS read READ COMMITTED data from the database / cache.
Summarizing:
ReadOnly cache can only read and insert, cannot perform Updates / deletes. The fastest execution.
Nonstrict Read Write Cache does not use any locks, there is always always a chance for dirty reads. However, it ALWAYS evicts the entry from the cache, so any subsequent messages always refer to the database.
Read Write cache uses locks, but in asynchronous order, first insert / update / delete occurs w / in tx. When a cache entry, softblocks and other sessions must reference the database. Once TX. completed, the lock is released and the cache is updated. (outside the transaction). In some cases, repeated readings may be compromised.
Transactional caches , obviously, updates the database and cache within the same transaction, so it is always in a consistent state with respect to the database.
Entity type , which are mostly updated and have parallel read and update, a read and write caching strategy may not be very useful, since most reads will be rejected into the database
Request cache
e need to enable the property below in our hibernate.cfg.xml 1
True
This option creates two new cache areas:
org.hibernate.cache.StandardQueryCache by storing the results of cached queries
org.hibernate.cache.UpdateTimestampsCache , containing the timestamps of the latest updates for the requested tables. They are used to check the results as they arrive from the query cache.
Query cache does not Query cache state of actual objects in the cache; it caches only identifier values and value type results. For this reason, the query cache should always be used in conjunction with the second level cache for those objects that are expected to be cached as part of the query result cache