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.

The following table shows which providers are compatible with which concurrency strategies.