hibernate.jdbc.batch_sizeを指定するポイントは何ですか？

Question

このHibernate構成は、第1レベルのキャッシュにキャッシュされるオブジェクトの数を表面的に制御する必要があります。理由は理解しやすいほど簡単ですが、私たちは記憶を使い果たしたくありません。

しかし、何か私を混乱させる。 this website を含む私が見たすべての実装には、明示的にフラッシュされクリアされています。問題はありませんが、構成プロパティのポイントは何ですか？

注：ここでは、Hibernateがキャッシュのサイズを何とか監視し、特定のタイプのオブジェクトの数がキャッシュサイズより大きくなるとキャッシュをdbと同期させると仮定します。その仮定が間違っているかどうか分かりませんか？

Answer 1

この設定オプションは、第1レベルのキャッシュのサイズとは関係ありません。セッションをフラッシュしても、キャッシュから何も削除されません。保留中の変更（挿入、削除、更新）をデータベースに書き込みます。キャッシュは、clear（）が明示的に呼び出された場合、またはセッションが閉じられた場合にのみクリアされます。セッションをクリアまたは句を指定しない（または特定のエンティティを拒否しない）場合、キャッシュは成長し続けます。これは、通常は非常に短命である（トランザクションの持続時間）ため、問題ではありません。

JDBCバッチ更新では、1回のバッチで複数の更新クエリをデータベースに送信できます。それはネットワークコールの数を減らします。 20個のファイルを個別に送信する代わりに、20個のファイルを含む圧縮されていないzipをアップロードしていると見なすことができます。

混乱は、あなたの質問にリンクされているページに記載されているバッチ更新がJDBCバッチ更新と何の関係もないという事実から来ています。バッチ更新でHibernateが意味することは、「バッチジョブによって行われた更新」です。バッチジョブは通常、典型的なビジネスユースケースよりもはるかに長いトランザクションを持ち、1つのトランザクションで数百、数千またはそれ以上のエンティティを更新します。このため、Hibernateはメモリ不足を避けるために、この場合はセッションを定期的にフラッシュしてクリアすることを推奨しています。