-
read-only
-
A read-only cache is good for data that needs to be read often but not modified. It is simple, performs well, and is safe to use in a clustered environment.
nonstrict read-write
-
Some applications only rarely need to modify data. This is the case if two transactions are unlikely to try to update the same item simultaneously. In this case, you do not need strict transaction isolation, and a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify
hibernate.transaction.manager_lookup_class
. In other environments, ensore that the transaction is complete before you callSession.close()
orSession.disconnect()
.
read-write
-
A read-write cache is appropriate for an application which needs to update data regularly. Do not use a read-write strategy if you need serializable transaction isolation. In a JTA environment, specify a strategy for obtaining the JTA TransactionManager by setting the propertyhibernate.transaction.manager_lookup_class. In non-JTA environments, be sure the transaction is complete before you call
Session.close()
orSession.disconnect()
.Note
To use the read-write strategy in a clustered environment, the underlying cache implementation must support locking. The build-in cache providers do not support locking.
transactional
-
The transactional cache strategy provides support for transactional cache providers such as JBoss TreeCache. You can only use such a cache in a JTA environment, and you must first specify
hibernate.transaction.manager_lookup_class
.