13.11. Infinispan

<div class="admonitionblock note">
<table>
<tr>
<td class="icon">

</td>
<td class="content">
<div class="paragraph">

Use of the build-in integration for [Infinispan](http://infinispan.org/) requires that the `hibernate-infinispan module` jar (and all of its dependencies) are on the classpath.

</div>
</td>
</tr>
</table>
</div>
<div class="paragraph">

Infinispan currently supports all cache concurrency modes, although not all combinations of configurations are compatible.

</div>
<div class="paragraph">

Traditionally the `transactional` and `read-only` strategy was supported on _transactional invalidation_ caches. In version 5.0, further modes have been added:

</div>
<div class="ulist">

• non-transactional invalidation caches are supported as well with read-write strategy. The actual setting of cache concurrency mode (read-write vs. transactional) is not honored, the appropriate strategy is selected based on the cache configuration (non-transactional vs. transactional).
• read-write mode is supported on non-transactional distributed/replicated caches, however, eviction should not be used in this configuration. Use of eviction can lead to consistency issues. Expiration (with reasonably long max-idle times) can be used.
• nonstrict-read-write mode is supported on non-transactional distributed/replicated caches, but the eviction should be turned off as well. In addition to that, the entities must use versioning. This mode mildly relaxes the consistency - between DB commit and end of transaction commit a stale read (see example) may occur in another transaction. However this strategy uses less RPCs and can be more performant than the other ones.

• read-only mode is supported on both transactional and non-transactional invalidation caches and non-transactional distributed/replicated caches, but use of this mode currently does not bring any performance gains. </div>

  The available combinations are summarized in table below:

  </div>

  Table 6. Cache concurrency strategy/cache mode compatibility table

  Concurrency strategy	Cache transactions	Cache mode	Eviction

  transactional </td>

  transactional </td>

  invalidation </td>

  yes </td> </tr>

  read-write </td>

  non-transactional </td>

  invalidation </td>

  yes </td> </tr>

  read-write </td>

  non-transactional </td>

  distributed/replicated </td>

  no </td> </tr>

  nonstrict-read-write </td>

  non-transactional </td>

  distributed/replicated </td>

  no </td> </tr> </tbody> </table>

  If your second level cache is not clustered, it is possible to use local cache instead of the clustered caches in all modes as described above.

  </div>

  Example 336. Stale read with `nonstrict-read-write` strategy

  `A=0 (non-cached), B=0 (cached in 2LC)
  TX1: write A = 1, write B = 1
  TX1: start commit
  TX1: commit A, B in DB
  TX2: read A = 1 (from DB), read B = 0 (from 2LC) // breaks transactional atomicity
  TX1: update A, B in 2LC
  TX1: end commit
  Tx3: read A = 1, B = 1 // reads after TX1 commit completes are consistent again`

  </div> </div> </div>