ReCache ってなんだろう？

前回は @DbLookup や @DbColmun のキャッシュの動作について検証しましたが、ReCache と NoCache の違いまでは発見できませんでした。NoCache はその名の通り、キャッシュせずに最新の結果を取得するのだとわかります。そこで、今回は ReCache についてもう少し詳細なテストを行い、挙動を見極めたいと思います。

前回のマスタ DB とフォームをテスト環境として使用しながら、いくつかの実験を行います。ReCache については、私自身使用経験がなかったので、興味津々です(笑)

テスト①：ビューをキャッシングしているのか？

ビューに表示される結果は、索引として保持されています。これをキャッシングしていて、ReCache で更新できるのではないか？という仮説のテストを行います。

今回のフォームでは住所の 6 フィールドはすべて SchZip ビューにアクセスしています。そこで、最初のフィールドにだけ ReCache を指定して、残りのフィールドはキャッシュから取得するようにしてみました。

この状態で実行して、一番下のフィールドが最新の値を取得したなら仮説の証明となります。

エージェントを実行すると Addr3 の値は更新時刻とは一致しませんでした。この結果より、この仮説は間違いであり、ビューをキャッシングしているのではないことがわかりました。

テスト②：検索結果（文書）をキャッシングしているのか？

@DbLookup の結果をビュー列からの取得ではなく、フィールド名を指定した取得に変更します。そして、前段の Kana2 フィールドの @DbLookup で ReCache を行います。

キャッシングの機能が文書をキャッシュしているなら、Addr3 フィールドでも最新の値が取得できるのではないか？という仮説の検証です。

この検証も結果は NG で、文書をキャッシングしているのではないようです。

テスト③：同じ検索結果の場合

一体何をキャッシュしているのかよくわからないので、式を同じにしてテストしてみます。ただ、1 フィールド Kana2 だけ、ReCache を指定してテストします。

結果は、次の通り ReCache を指定したフィールド以降は正しく取得できています。やっとキャッシュっぽい動作を確認できました...

テスト④：キャッシュしているのは列？

最後のテストは複合パターンです。

テスト③ と同様のパターンで検索する式をいったん揃えます。指定する式はテスト①と同様列番号を指定するタイプに戻しました。そのうえで、Kana2 だけ別の郵便番号を ReCache で取得します。列全体がキャッシュされているならこのフィールド以降が最新の値となります。

さらに追加のテストで、Kana3 は Addr3 と同じ式ですが ReCache で取得します。これはテスト③と同様のテストですね。

このテストケースで実行したところ、結果は以下の通りで、Addr2 の値はキャッシュから取得されました。また、Kana3 で実行した ReCache の効果で、Addr3 は最新の値となっています。

まとめ

この結果より、キャッシュは検索条件が同じで、取得する列（値？）が同じ場合に限りキャッシュしているようです。実アプリのおいて、同じ検索で同じ値を複数取得するシーンが思い浮かばないので ReCache の価値や使いどころは残念ながらわかりません。

現時点では、

• マスタの更新頻度が高い場合や最新の値が必要な場合には NoCache を指定
• 更新頻度が低い場合や追加型のダイアログフィールドのように選択肢を提供するだけの機能の場合にはキャッシュさせてもよい

という程度の使い分けでよいかな という判断をしました。今後、この認識にアップデートがあれば改めて記事にしたいと思います。

ところで、キャッシュは、レスポンス（パフォーマンス）向上が一般的な目的となります。次回は、キャッシュの設定と効果について検証したいと思います。