Using Eviction and Expiration Operations

Entry expiration and LRU eviction affect the committed state. They are not part of the transaction, and they cannot be rolled back.

Eviction

LRU eviction operations do not cause write conflicts with existing transactions, despite destroying or invalidating entries. LRU eviction is deferred on entries modified by the transaction until the commit completes. Because anything touched by the transaction has had its LRU clock reset, eviction of those entries is not likely to happen immediately after the commit.

When a transaction commits its changes in a region with distributed scope, the operation can invoke eviction controllers in the remote caches, as well as in the local cache.

Configure Expiration

Local expiration actions do not cause write conflicts, but distributed expiration can cause conflicts and prevent transactions from committing in the members receiving the distributed operation.
  • Using local expiration with transactions. When you are using transactions on a region, make expiration local, if possible. For every instance of that region, configure an expiration action of local invalidate or local destroy. In a cache.xml declaration, use a line similar to this:
    <expiration-attributes timeout="60" action="local-invalidate"/>
    In regions modified by a transaction, local expiration is suspended. Expiration operations are batched and deferred per region until the transactions complete. Once cleanup starts, the manager processes pending expirations. Transaction that need to change the region wait until the expirations are complete.

  • Using distributed expiration with transactions. With partitioned and replicated regions, you cannot use local expiration. When you are using distributed expiration, the expiration is not suspended during a transaction, and expiration operations distributed from another member can cause write conflicts. In replicated regions, you can avoid conflicts by setting up your distributed system this way:
    1. Choose an instance of the region to drive region-wide expiration. Use a replicated region, if there is one.
    2. Configure distributed expiration only in that region instance. The expiration action must be either invalidate or destroy. In a cache.xml declaration, use a line similar to this
      <expiration-attributes timeout="300" action="destroy"/>
    3. Run your transactions in the member where you configured expiration.