Une Session
Hibernate est un cache de niveau transactionnel des données persistantes. Il est possible de configurer un cache de cluster
ou de JVM (de niveau SessionFactory
pour être exact) défini classe par classe et collection par collection. Vous pouvez même utiliser votr choix de cache en
implémentant le pourvoyeur (provider) associé. Faites attention, les caches ne sont jamais avertis des modifications faites
dans la base de données par d'autres applications (ils peuvent cependant être configurés pour régulièrement expirer les données
en cache).
Par défaut, Hibernate utilise EHCache comme cache de niveau JVM (le support de JCS est désormais déprécié et sera enlevé des
futures versions d'Hibernate). Vous pouvez choisir une autre implémentation en spécifiant le nom de la classe qui implémente
org.hibernate.cache.CacheProvider
en utilisant la propriété hibernate.cache.provider_class
.
Tableau 19.1. Fournisseur de cache
Cache | Classe pourvoyeuse | Type | Support en Cluster | Cache de requêtes supporté |
---|---|---|---|---|
Hashtable (not intended for production use) | org.hibernate.cache.HashtableCacheProvider |
mémoire | yes | |
EHCache | org.hibernate.cache.EhCacheProvider |
mémoire, disque | yes | |
OSCache | org.hibernate.cache.OSCacheProvider |
mémoire, disque | yes | |
SwarmCache | org.hibernate.cache.SwarmCacheProvider |
en cluster (multicast ip) | oui (invalidation de cluster) | |
JBoss Cache 1.x | org.hibernate.cache.TreeCacheProvider |
en cluster (multicast ip), transactionnel | oui (replication) | oui (horloge sync. nécessaire) |
JBoss Cache 2 | org.hibernate.cache.jbc2.JBossCacheRegionFactory |
en cluster (multicast ip), transactionnel | yes (replication or invalidation) | oui (horloge sync. nécessaire) |
L'élément <cache>
d'une classe ou d'une collection à la forme suivante :
<cache usage="transactional|read-write|nonstrict-read-write|read-only" (1) region="RegionName" (2) include="all|non-lazy" (3) />
|
|
|
|
|
|
Alternatively (preferably?), you may specify <class-cache>
and <collection-cache>
elements in hibernate.cfg.xml
.
L'attribut usage
spécifie une stratégie de concurrence d'accès au cache.
Si votre application a besoin de lire mais ne modifie jamais les instances d'une classe, un cache read-only
peut être utilisé. C'est la stratégie la plus simple et la plus performante. Elle est même parfaitement sûre dans un cluster.
<class name="eg.Immutable" mutable="false"> <cache usage="read-only"/> .... </class>
Si l'application a besoin de mettre à jour des données, un cache read-write
peut être approprié. Cette stratégie ne devrait jamais être utilisée si votre application nécessite un niveau d'isolation
transactionnelle sérialisable. Si le cache est utilisé dans un environnement JTA, vous devez spécifier hibernate.transaction.manager_lookup_class
, fournissant une stratégie pour obtenir le TransactionManager
JTA. Dans d'autres environnements, vous devriez vous assurer que la transation est terminée à l'appel de Session.close()
ou Session.disconnect()
. Si vous souhaitez utiliser cette stratégie dans un cluster, vous devriez vous assurer que l'implémentation de cache utilisée
supporte le vérrouillage. Ce que ne font pas les pourvoyeurs caches fournis.
<class name="eg.Cat" .... > <cache usage="read-write"/> .... <set name="kittens" ... > <cache usage="read-write"/> .... </set> </class>
Si l'application besoin de mettre à jour les données de manière occasionnelle (qu'il est très peu probable que deux transactions
essaient de mettre à jour le même élément simultanément) et qu'une isolation transactionnelle stricte n'est pas nécessaire,
un cache nonstrict-read-write
peut être approprié. Si le cache est utilisé dans un environnement JTA, vous devez spécifier hibernate.transaction.manager_lookup_class
. Dans d'autres environnements, vous devriez vous assurer que la transation est terminée à l'appel de Session.close()
ou Session.disconnect()
La stratégie de cache transactional
supporte un cache complètement transactionnel comme, par exemple, JBoss TreeCache. Un tel cache ne peut être utilisé que
dans un environnement JTA et vous devez spécifier hibernate.transaction.manager_lookup_class
.
None of the cache providers support all of the cache concurrency strategies.
The following table shows which providers are compatible with which concurrency strategies.
Tableau 19.2. Stratégie de concurrence du cache
Cache | read-only (lecture seule) | nonstrict-read-write (lecture-écriture non stricte) | read-write (lecture-ériture) | transactional (transactionnel) |
---|---|---|---|---|
Hashtable (not intended for production use) | yes | yes | yes | |
EHCache | yes | yes | yes | |
OSCache | yes | yes | yes | |
SwarmCache | yes | yes | ||
JBoss Cache 1.x | yes | yes | ||
JBoss Cache 2 | yes | yes |