19.2. Le cache de second niveau

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)

19.2.1. Mapping de Cache

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)
/>
(1)

usage (requis) spécifie la stratégie de cache : transactionel, lecture-écriture, lecture-écriture non stricte ou lecture seule

(2)

region (optionnel, par défaut il s'agit du nom de la classe ou du nom de role de la collection) spécifie le nom de la région du cache de second niveau

(3)

include (optionnel, par défaut all) non-lazy spécifie que les propriétés des entités mappées avec lazy="true" ne doivent pas être mises en cache lorsque le chargement tardif des attributs est activé.

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.

19.2.2. Strategie : lecture seule

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>

19.2.3. Stratégie : lecture/écriture

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>

19.2.4. Stratégie : lecture/écriture non stricte

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()

19.2.5. Stratégie : transactionelle

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.

19.2.6. Cache-provider/concurrency-strategy compatibility

Important

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