TDVキャッシュポリシー機能の利用方法について説明します。
本手順では、データソースとしてPostgreSQL(TDVリポジトリとは別のインスタンス)を利用し、外部キャッシュデータベースとして Oracle 19c を利用します。
キャッシュポリシーとは
キャッシュポリシーは、複数リソースのグループに対する更新スケジュールを定義するものです。
複数のキャッシュされたリソース間の一貫性を維持するために使用します。
例えば、以下のような3件のデータソース、3件の中間ビューで構成されるビューがあり、すべてのリソースがキャッシュ化されている場合に、キャッシュ更新時に一部のリソースで更新が失敗すると最終ビュー(右端のorderDetails
)の結果が意図しないものとなる可能性があります。
そのような事態を防ぐために、キャッシュポリシーを利用します。
それにより、一斉更新時にどれか1つでもリソースのキャッシュ更新が失敗した場合にすべてのキャッシュ更新がロールバックされます。
また、キャッシュポリシーは増分キャッシュには対応していませんので、ご注意ください。
検証環境
PostgreSQLをデータソースするビューorderDetails
を構成するすべてのデータソース・ビューに対して以下のようにキャッシュ設定を行います。
本記事では、各リソースに対するキャッシュ設定方法(外部キャッシュターゲット方式)については説明しません。
この例では、キャッシュターゲットとして外部のOracleデータソースを利用し、「複数テーブルモード」(3テーブル)でキャッシュ設定されています。
(任意)更新前後実行用プロシージャの作成
キャッシュポリシーによりキャッシュ化されたリソース群のキャッシュデータ更新時に実行することができるプロシージャを作成します。
プロシージャの作成は必須ではありません。
更新前実行用プロシージャ
以下の例のようにプロシージャを作成します。
この例では、キャッシュ更新開始前にログを出力するシンプルな処理が記述されています。
プロシージャ記述例:
PROCEDURE pDemoPreRefresh() -- This procedure is used as a Cache Policy Pre-refresh callback procedure. -- It will be called once for each resource used in the cache policy. BEGIN DECLARE cachedResourcePath LONGVARCHAR; -- GetEnvironment returns the path to the resource about to be cached. CALL GetEnvironment ('System.CACHED_RESOURCE_PATH', cachedResourcePath); -- Log entry will be written to cs_server.log CALL LOG ('Cache refresh started on ' || cachedResourcePath); END
更新後実行用プロシージャ
以下の例のようにプロシージャを作成します。
この例では、キャッシュ更新完了後にログを出力するシンプルな処理が記述されています。
プロシージャ記述例:
PROCEDURE pDemoPostRefresh() -- This procedure is used as a Cache Policy Post-refresh callback procedure. -- It will be called once for each resource used in the cache policy. BEGIN DECLARE cachedResourcePath LONGVARCHAR; -- GetEnvironment returns the path to the resource that has just been cached. CALL GetEnvironment ('System.CACHED_RESOURCE_PATH', cachedResourcePath); -- Log entry will be written to cs_server.log CALL LOG ('Cache refresh finished on ' || cachedResourcePath); END
キャッシュポリシー設定
以下の手順に従い、キャッシュポリシーを設定します。
1. TDV Studio ソースツリー(左ペイン)内の /policy/cache
( [ホスト名] > policy > cache
)を右クリックし、新規
> 新しいキャッシュポリシー
をクリックします。
2. 任意の名前を設定します。
3. リソースタブにて、キャッシュポリシーとしてグループ化するキャッシュ化されたリソースをすべてリソース欄に追加します。
リソースはソースツリーからドラッグ・アンド・ドロップで追加できます。
キャッシュ更新の順番について
キャッシュポリシーのリソース一覧に追加されたリソース群のキャッシュがキャッシュポリシーによって一括更新される際には、それらの依存関係を考慮した順番で更新されます。
上記の例では、対象のリソース群には依存・参照の関係があるため、以下の順番で更新されます。
- 依存するリソースがないリソース群
/shared/cache_demo/cache_policy/datasource/demo_postgres/cache_policy/orders
/shared/cache_demo/cache_policy/datasource/demo_postgres/cache_policy/products
/shared/cache_demo/cache_policy/datasource/demo_postgres/cache_policy/stores
- 1に依存するリソース群
/shared/cache_demo/cache_policy/view/L1_Physical/orders
/shared/cache_demo/cache_policy/view/L1_Physical/products
/shared/cache_demo/cache_policy/view/L1_Physical/stores
- 2に依存するリソース群
/shared/cache_demo/cache_policy/view/L2_Business/orderDetails
有効期限スケジュール
リフレッシュされたキャッシュデータの有効期限を設定することができます。
バージョン8.5.5の時点で設定フィールドが耐障害性ポリシーメニューと一部が重なっていますが、マウスカーソルをホバーさせることでフィールドが見えるようになりますので、設定することができます。
耐障害性ポリシーについて
バージョン8.5.5の時点では耐障害性ポリシーとして「All or Nothing」(TDV Studio上では「すべて有効またはすべて無効」と表記)のみが選択可能であり、そのモードが設定されています。
キャッシュポリシーでは、キャッシュデータの一貫性はオール・オア・ナッシングです。
キャッシュポリシーに含まれるリソースの1つが更新アクション中に失敗した場合、すべてのキャッシュは、前回成功したデータのスナップショットにロールバックされます。
このため、キャッシュポリシーと増分キャッシングの併用はサポートされていません。
ロールバックの例を以下に示します。
ユーザーは、キャッシュポリシーに 10 件のキャッシュ対象リソースを追加しました。
キャッシュポリシーを起動したところ、最初の6件のリソースのキャッシュ更新は成功しましたが、7件目のキャッシュ更新は失敗しました。
このとき、TDVは7件目のリソースのキャッシュ更新の失敗をスキップして8,9,10件目のリソースのキャッシュ更新を続行することはありません。
代わりに、TDVはロールバックを行います。つまり、TDVは成功した6件のリソースの更新をすべて取り消し、キャッシュポリシーがまったく実行されていなかった場合と同じ状態に戻します。
キャッシュポリシー動作確認(正常系)
キャッシュを更新(初期化)して正常系の動作を確認してみます。
1. キャッシュポリシーのキャッシュポリシーの設定タブで今すぐ更新ボタンをクリックします。
注)各リソースのキャッシュタブではありません。
2. 正常にキャッシュが初期化され、ステータスが UP となることを確認します。
3. cache_status
テーブルを確認し、キャッシュ初期化処理が実行されたことを確認します。
4. orderDetails
ビューの実行プランを確認し、キャッシュポリシーが有効になっていることと、外部キャッシュデータベースに対してFETCH(クエリ実行によるデータ取得)が実行されていることを確認します。
5. 更新前のアクションおよび更新後のアクションにログ出力処理を実装したプロシージャが指定されている場合は、 [TDVインストールフォルダ]\logs\cs_server.log
にログが出力されていることを確認します。
ログ出力例:
INFO [Cache Refresh for /policy/cache/DemoPolicy] 2022-01-01 17:30:09.979 +0900 LogProcedure - Cache refresh started on /policy/cache/DemoPolicy INFO [Cache Refresh for /policy/cache/DemoPolicy] 2022-01-01 17:30:13.306 +0900 LogProcedure - Cache refresh finished on /policy/cache/DemoPolicy
6. ビューを実行し、これまでと同じようにデータが取得できることを確認します。
キャッシュのリフレッシュ - INSERT/UPDATE/DELETE
データソース(PostgreSQL)に対して、INSERT/UPDATE/DELETEが実行された後にキャッシュをリフレッシュし、デフォルトキャッシュテーブル内のデータにも変更が反映されることを確認します。
データソースのorders
、products
、stores
テーブルに対し以下のような変更を加えます。
orders
products
stores
しかし、この時点でorderDetails
ビューを実行しても以下のとおりレコード変更は反映されていません。
キャッシュを最新化するために、以下の手順でキャッシュテーブルに対してキャッシュをリフレッシュします。
1. キャッシュポリシーの設定タブの更新モードにある今すぐ更新ボタンをクリックし、キャッシュをリフレッシュします。
2. ダイアログが表示されるのでOKボタンをクリックします。
3. 正常にキャッシュがリフレッシュされ、ステータスが UP となっていることを確認します。
4. 再度、orderDetails
ビューを実行し、レコード追加が反映されていることを確認します。
キャッシュポリシー動作確認(異常系)
キャッシュポリシーでグループ化しているキャッシュ化されたリソース群のうち一部のリソースでキャッシュ更新できなかった場合の動作を確認してみます。
キャッシュのリフレッシュ - INSERT/UPDATE/DELETEと同じように、データソース側にいくつかの変更を加えてからキャッシュ更新を行います。
今回は、以下のリネージュのうち、stores
、orders
、products
の3件のデータソースオブジェクトのキャッシュ更新ができない場合の動作を確認します。
1. データソースのキャッシュ更新を失敗させるために、データソースを無効化します。
2. キャッシュポリシーのキャッシュポリシーの設定タブで今すぐ更新ボタンをクリックしキャッシュ更新が失敗すること、ステータスが STALE となることを確認します。
注)各リソースのキャッシュタブではありません。
3. orderDetails
ビューを実行しても以下のとおりキャッシュに変更が反映されていないことを確認します。