4.5. キャッシュ¶
ここでは、Web実行環境におけるHTTPセッションを利用したアクセスコンテキストのキャッシュ機構について説明します。
項目
4.5.1. 概要¶
アクセスコンテキストのライフサイクルは、 Lifecycle#begin() から Lifecycle#end() が呼び出されるまでです。そのため、Web実行環境では1つのHTTPリクエストに対する処理が終了するとアクセスコンテキストは破棄されます。一般的なWebアプリケーションにおけるユーザ情報は、ログインによりHTTPセッションに格納され、ログアウトするまで有効となります。intra-mart Accel Platform では上記を実現するために、ユーザ情報を格納しているアクセスコンテキストをHTTPセッションにキャッシュすることで、ユーザ情報をHTTPセッションと同じスコープで保持する仕組みを提供します。キャッシュを利用する設定は、アクセスコンテキストごとに行います。キャッシュを利用しなかった場合、リクエストごとにアクセスコンテキストが生成されることになります。そのため、ログイン後に生成した情報を引き継ぐことができず、毎回初期状態のアクセスコンテキストが生成されてしまいます。また、毎回アクセスコンテキストが生成されることにより、パフォーマンスの低下を招きます。コンテキストスイッチ実行時は、キャッシュは破棄されます。ただし、コンテキストスタック実行中にコンテキストスイッチを実行された場合は、キャッシュの破棄、および、登録は行われません。コンテキストスイッチ前のアクセスコンテキストを引き継ぐ場合、コンテキストビルダにより適切な処理が必要です。コラム
この機能は、アクセスコンテキストをキャッシュするための仕組みです。頻繁にアクセスする情報をキャッシュするための機能は、 intra-mart Accel Platform の 「Cacheサービス」を利用してください。「Cacheサービス」については、以下のドキュメントを参照してください。
4.5.2. キャッシュの処理フロー¶
キャッシュ処理の流れを、以下の順に説明します。
- ライフサイクル開始時の、キャッシュの取得・更新
- コンテキストスイッチによるキャッシュの更新
4.5.2.1. キャッシュの取得・更新処理フロー¶
キャッシュ利用時は、ライフサイクル開始処理でキャッシュを利用するための処理が実行されます。ライフサイクル開始時の、キャッシュの取得・更新処理の流れは、以下の通りです。
コンテキスト生成開始 キャッシュ取得キャッシュからアクセスコンテキストを取得します。
- キャッシュからアクセスコンテキストが取得できた場合、「3. キャッシュタイムアウト判定」を行います。
- キャッシュからアクセスコンテキストが取得できなかった場合、「5. アクセスコンテキスト生成」を行います。
キャッシュタイムアウト判定設定されたキャッシュタイムアウト判定方式に従って、キャッシュタイムアウトの判定を行います。
- キャッシュタイムアウト判定によりキャッシュ有効となった場合、キャッシュを利用してライフサイクルを開始します。
- キャッシュタイムアウト判定によりキャッシュ無効となった場合、「4. キャッシュ削除」を行います。
キャッシュ削除キャッシュ無効となった場合、キャッシュからアクセスコンテキストを削除します。 アクセスコンテキスト生成新しいアクセスコンテキストを生成します。この場合、キャッシュタイムアウト前のアクセスコンテキストを参照して生成することができます。 キャッシュ保存新しいアクセスコンテキストをキャッシュに保存します。
4.5.3. キャッシュ実装¶
キャッシュを利用するためには、以下の対応が必要です。
ライフサイクル開始処理では、CachingContextBuilderSupport クラスを継承したコンテキストビルダ利用する。
Web実行環境用の標準アクセスコンテキストは、キャッシュをサポートしています。コンテキストスイッチ処理では、StandardSwitchableContextBuilder クラスを利用する。
完全修飾クラス名(FQCN)jp.co.intra_mart.system.context.standard.StandardSwitchableContextBuilder
StandardSwitchableContextBuilder クラスは、コンテキストスイッチでキャッシュをサポートするためのコンテキストビルダで、アクセスコンテキストの生成処理は行いません。新しいアクセスコンテキストを生成するためには、コンテキストデコレータを利用します。設定例
<builder target="sample.resource.id"> <!-- キャッシュをサポートするコンテキストスイッチ用コンテキストビルダ --> <builder-class>jp.co.intra_mart.system.context.standard.StandardSwitchableContextBuilder</builder-class> <!-- コンテキストデコレータを必要な数だけ指定します。 --> <decorator> <!-- コンテキストスイッチで新しいアクセスコンテキストを生成するための、 コンテキストデコレータの実装クラスを指定します。 --> <decorator-class>sample.SampleContextSwitchDecorator</decorator-class> </decorator> </builder>
4.5.4. キャッシュ設定¶
キャッシュを利用する場合は、のコンテキストビルダは、CachingContextBuilderSupport クラスを継承している必要があります。デフォルトコンテキストビルダには、制約はありません。Web実行環境用の標準アクセスコンテキストは、 デフォルトコンテキストビルダをサポートしています。キャッシュを利用する場合、アクセスコンテキスト設定ファイルに設定を行います。キャッシュの設定は実行環境開始時に決定するため、実行環境開始用のコンテキストビルダの初期パラメータに設定します。
初期パラメータのキー cache-policy 初期パラメータの値 「 キャッシュタイムアウト判定方式一覧 」の設定値 Web実行環境の開始用コンテキストビルダのリソースIDは、「 platform.request 」ですので、対象のコンテキストビルダ設定に以下のように設定します。<context name="sample.SampleContext"> <builder target="platform.request"> <builder-class>sample.SampleContextBuilder</builder-class> <!-- キャッシュの利用とキャッシュタイムアウト判定方式の設定 --> <init-param> <param-key>cache-policy</param-key> <param-value>session-user-daily</param-value> </init-param> </builder> </context>初期パラメータの値に設定する値は、「 キャッシュタイムアウト判定 」を指定するための設定になります。「 キャッシュタイムアウト判定方式一覧 」から、適切な値を設定してください。
4.5.5. キャッシュタイムアウト判定¶
Web実行環境のアクセス時には、リクエストごとにキャッシュタイムアウトの判定が行われます。これにより、一定期間経過後にアクセスコンテキストの情報を更新することが可能です。ただし、コンテキストスイッチ処理では、常にキャッシュを破棄して新しいアクセスコンテキストが保存されます。
4.5.5.1. キャッシュタイムアウト判定方式一覧¶
以下のキャッシュタイムアウト判定方式が利用できます。
表 キャッシュタイムアウト判定方式一覧 設定値 判定方式 session-daily 1日が経過したら、キャッシュ無効とします。1日の経過とは、システムのタイムゾーンでの時刻が 「00:00:00」 になった時点を指します。session-user-daily 1日が経過したら、キャッシュ無効とします。session-daily とは異なり、ユーザのタイムゾーンでの日時を利用します。1日の経過とは、ユーザのタイムゾーンでの時刻が 「00:00:00」 になった時点を指します。session-interval 指定時間が経過したら、キャッシュ無効とします。指定時間は設定ファイルの初期パラメータのキー「 cache-interval 」に時間(分)を指定します。指定時間の基準は、アクセスコンテキスト生成時(初回アクセス時、またはスイッチ時)からです。session-infinite 常にキャッシュ有効とします。コンテキストスイッチ実行時のみキャッシュが破棄されます。標準アクセスコンテキストでは、以下のキャッシュタイムアウト判定方式が設定されています。
表 標準アクセスコンテキストのキャッシュタイムアウト判定方式一覧 コンテキスト種別 キャッシュタイムアウト判定方式 アカウントコンテキスト session-user-daily クライアントコンテキスト session-infinite ユーザコンテキスト session-user-daily 認可サブジェクトコンテキスト session-user-daily ジョブスケジューラコンテキスト Web実行環境で利用しないため、設定なし。 注意
依存関係があるアクセスコンテキストの場合、依存先と同じキャッシュ設定をする必要があります。依存関係があるアクセスコンテキストのキャッシュタイムアウト判定方式が異なる場合、キャッシュタイムアウトのタイミングが異なるため、アクセスコンテキストの情報に不整合が発生する場合があります。