4.3. 有効期限の詳細

有効期限 は、設定およびキャッシュ API において示されるトップレベルのコンストラクトです。
エビクションは 各キャッシュインスタンスに対してローカル ですが、有効期限は クラスター全体 になります。expiration lifespan および maxIdle の値は、キャッシュエントリーとともにレプリケートされます。
キャッシュエントリーの最大アイドル時間には、クラスター環境で追加のネットワークメッセージが必要になります。このため、クラスター化されたキャッシュに maxIdle を設定すると、操作が遅くなる可能性があります。
有効期限のライフサイクルおよび maxIdle は CacheStore でも永続化されるため、この情報はエビクション/パッシベーション後も維持されます。

最大アイドル有効期限は、ローカルおよびクラスターキャッシュ環境での動作が異なります。

重要

アイドルの最大有効期限( max-idle )は、現在オフヒープメモリーに保存されるエントリーとは機能しません。同様に、キャッシュストアを永続レイヤーとして使用する場合、max-idle は動作しません。

ローカルキャッシュモードでは、Red Hat Data Grid は以下の場合に maxIdle 設定でエントリーを失効させます。

クラスター化されたキャッシュモードでは、クライアントが max-idle 有効期限の値を持つエントリーを読み取ると、Red Hat Data Grid は touch コマンドをすべての所有者に送信します。これにより、エントリーの相対アクセス時間がクラスター全体で同じになります。

ノードがエントリーの最大アイドル時間に到達することを検出すると、Red Hat Data Grid はキャッシュから削除され、要求したクライアントにエントリーを返しません。

クラスター化されたキャッシュモードで max-idle を使用する前に、以下の点を確認する必要があります。

cache.get（） は、タッチコマンドが完了するまで返されません。この同期動作により、クライアント要求のレイテンシーが長くなります。
クラスター化された max-idle は、Red Hat Data Grid がエビクションに使用するすべての所有者のキャッシュエントリーの「最近アクセスした」メタデータも更新します。
クラスター化されたキャッシュでの反復を行うと、最大アイドル時間で有効期限が切れる可能性があるエントリーが返されます。この動作は、反復中にリモート呼び出しが実行されないため、パフォーマンスが向上します。ただし、期限切れリーパーによって削除されるエントリーや直接アクセスする場合（Cache.get（））は期限切れのエントリーは更新されません。

重要