Pivotal GemFire® v9.5

How Expiration Works

Expiration keeps a region’s data fresh by removing old entries and entries that you are not using. You can choose whether expired entries are invalidated or destroyed.


This figure shows two basic expiration settings for a client/server system. The server (on the right) populates the region from a database and the data is automatically distributed throughout the system. The data is valid for only one hour, so the server performs a distributed destroy on entries that are an hour old. The client applications are consumers. The clients free up space in their caches by removing their local copies of the entries for which there is no local interest (idle-time expiration). Requests for entries that have expired on the clients will be forwarded to the server.

Expiration Types

Pivotal GemFire provides two types of expiration, each triggered by a time-based threshold. These can co-exist; they are not mutually exclusive.


Expiration Actions

Pivotal GemFire provides the following expiration actions:

  • invalidate (default) - The data item’s value is deleted, but the key remains in the cache. Applies to all distributed members in which the data item is replicated.
  • destroy - The data item’s key and value are both deleted. Applies to all distributed members in which the data item is replicated.
  • local invalidate - Deletes the data item’s value. Applies only to the local member.
  • local destroy - Deletes the data item’s key and value. Applies only to the local member.

You cannot use local-destroy or local-invalidate expiration actions in replicated or partitioned regions. You can use the local options only on distributed regions with a data-policy of empty, normal or preloaded.

Entry Expiration in Replicated Regions and Partitioned Regions

In replicated regions, entry updates are performed in the most convenient available copy of the data, then replicated to the other members, resetting their last-updated statistics to the same time. In partitioned regions, entry updates are always done in the primary copy, resetting the primary copy’s last-updated and last-accessed statistics, then the secondary copies are updated to match.

In both replicated and partitioned regions, entry retrieval uses the most convenient available copy of the data, which may be any of the distributed copies. Retrievals are not propagated to other members. Differences in last-access times are reconciled when the data item is considered for expiration.

Expiration can be triggered in any copy of a replicated region, if the time elapsed since the last update or read access exceeds the established threshold. Expiration in partitioned regions is executed in the primary copy, based on the primary’s last-accessed and last-updated statistics. In both cases, the expiration mechanism checks the last-accessed dates of all copies of the data item and updates the last-access date of all copies to the most recent last-accessed date. Then, if the elapsed time still puts the data item over the expiration threshold, the item is deleted in accordance with the expiration action specified for the region.

Interaction Between Expiration Settings and netSearch

