Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。329件3EBean(6.17.3)にて、クエリーキャッシングを行なったとき、http://ebean-orm.github.io/docs/features/l2caching/異なるWHERE句のクエリに対して、キャッシュの値が返される場合があるようです。いわゆるハッシュ値の衝突が起きているようなのですが、あまりにも容易に衝突が起きているようなので、回避方法はないでしょうか?サンプルはPostgreSQLですが、特にDBMLには依存しないと思います。postgres;DBデータは以下です。id;column_a;column_b1;"SK08";"320"2;"SK09";"310"3;"SK01";"201"4;"SK11";"101"再現コードは以下です。columnB;}検索部分のコードは以下です。list3とlist4が同じ値を返します。(list2の検索時にlist1のキャッシュが返る。根本的には、以下のコードでhash1とhash2が同値になるのが原因です(EBeanのクエリーキャッシュのハッシュ値算出アルゴリズムを元に作成)。codeと桁ズレの組み合わせで容易にハッシュの衝突が起こるようです。h;これは(最もキャッシュが有効に機能するはずの)コードテーブルでは普通に想定できる事態だと思います。(ふたつの文字列カラムでレコードが決定する場合)問題が大きいですね・・・。9.1.1で解決するようです。https://github.com/ebean-orm/ebean/issues/869根本的な原因はハッシュキーを生成する際に31を用いた実装になっていたことです。|1結論としては、実用的な回避方法は(私の調べた限りでは)ありませんでした。eq()メソッドの呼び出し順序を変更すれば、ハッシュの値を変えることができますので、誤ったキャッシュを回避することができます。5.6.22コードを変更して検証しました。t2.columnB);この場合、クエリハッシュのハッシュコードはたしかに同一となり、キャッシュが利用されています。320list2のeq()メソッドの順序を入れ替えます。.query();すると、キャッシュは利用されません。310なお、エンティティクラスに@Cache(enableQueryCache=true)をつけています。個の銅バッジ再現テスト及びコメントありがとうございます。このケースが大丈夫であっても他のテーブルで同様の問題にぶつかる可能性が“高い”と思いました。ハッシュ生成のアルゴリズムを変えるようなプルリクエストを送るしかないですかね...。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。会を開催します🎉サイトの未翻訳箇所を見つけて、もくもく会で直しましょう関連する質問2JavaのWebアプリでMysqlに接続してクエリを実行するとエラーが発生する1パッケージ宣言とフォルダ配置が異なるソースファイルをエラーとして検知するには2GAEにおけるObjectifyを使用したクエリについて1iText7で異なるフォントを混ぜてパラグラフを作成する方法1javaでクエリから取得した値を変数に格納できません。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。