Hibernateのキャッシュについて考えてみる（その２）
前回は、Hiberanteの２次キャッシュを、単純に技術的に適用して動かすだけなら簡単だけど、適切に設計して実案件に取り込むのはハードルが高そうだねぇという話でした。今回は、キャッシュ関連の分類と、キャッシュプロバイダ実装側の対応について考えてみようと思います。
Hibernateのマニュアルでは、キャッシュに関して以下のように分類されています。
Hibernate 実装依存の分類
Cache Concurrency Strategy
これは、Hibernateがデフォルトで用意しているキャッシュ戦略です。キャッシュプロバイダ実装が、すべての戦略をサポートすることを義務付けられているわけではありません。(Table 19.2. Cache Concurrency Strategy Support)
Cache Provider 実装に関する分類
Table 19.1. Cache Providersでは、以下のように分類されています。
Cache Provider の Type（排他ではない）
- memory
- disk
- clustered
- transactional
Cluster Safe
- yes
- no
Query Cache Supported
- yes
- no
しかし、分類についての説明は特にされていません。たとえば、clustered とか Cluster Safe の正確な定義はよくわかりません。
対応はキャッシュプロバイダ次第
Hibernate 側ではマニュアル上、上記のように分類しているわけですが、基本的にすべてオプショナルです。そのため、キャッシュプロバイダへの依存が大きくなっています。そうなると、利用者としては、以下のような点が気になります。
各キャッシュライブラリ（OSCache や EHCacheなど）の持つ機能とHibernate側の兼ね合い
たとえば、キャッシュライブラリ側の設定としてエントリ数に上限を設けたLRUキャッシュ設定を使用し、Hibernate側の設定としてはクエリキャッシュを使用するとか普通に考えそうですが、設定上の制約ってどうなんでしょうか。
仕様のグレーゾーンの扱い
キャッシュプロバイダの仕様について、Hibernate 側からマニュアルおよび java の interface が提供されています。しかし、明文化されていないグレーゾーンについて、キャッシュプロバイダの実装側との意識がどの程度合っているのが気になります。「hiberante にバグがあるためにパッチを送ったけど Hibernate 側が対応してくれない」と主張しているキャッシュプロバイダ実装者もいるようですが、利用者側から見たら、どっちでもいいからきちんと動くものを提供してほしいですよね。
キャッシュプロバイダの実装品質
さまざまな機能を付加してしのぎを削るのはいいのですが、高負荷でも安心して使える実装がほしいところです。実際においらは、高負荷の案件でOSCacheとEhCacheを使用した際、両方のライブラリにおいて実用に耐えない多くの問題を確認した経験があります。(´･ω･`)
まとめ
今回は、キャッシュ関連の分類と、キャッシュプロバイダ実装側の対応について考えてみました。分類にもいろいろあり、実装にもいろいろあって、一気にすべて理解するのは難しそうです。ということで、次回は Cache Concurrency Strategy にフォーカスしてみようとおもいます。
