このHibernate構成は、表面上、第1レベルのキャッシュにキャッシュされるオブジェクトの数を制御する必要があります。その理由は簡単に理解できます。メモリが不足したくないのです。
しかし、何かが私を混乱させています。このWebサイトを含め、私が見たすべての実装に は、明示的なフラッシュとクリアがあります。問題ありませんが、構成プロパティのポイントは何ですか？
注：ここでは、Hibernateがキャッシュのサイズを監視し、特定のタイプのオブジェクトの数がキャッシュサイズよりも大きくなった場合に、キャッシュをデータベースと同期すると想定しています。その仮定が間違っているかどうかわからない???
この構成オプションは、第1レベルのキャッシュのサイズとは関係ありません。また、セッションをフラッシュしても、キャッシュから何も削除されません。保留中の変更（挿入、削除、更新）をデータベースに書き込みます。キャッシュは、clear（）が明示的に呼び出された場合、またはセッションが閉じられた場合にのみクリアされます。セッションをクリアまたは句読しない場合（または特定のエンティティをエビストしない場合）、キャッシュはどんどん大きくなります。通常は非常に短命（トランザクションの期間）であるため、これは問題ではありません。
JDBCバッチ更新を使用すると、複数の更新クエリを1つのバッチでデータベースに送信できます。ネットワーク呼び出しの数を減らします。20個のファイルを個別に送信するのではなく、20個のファイルを含む非圧縮のzipをアップロードするものとして表示できます。
混乱は、質問にリンクされているページに記載されているバッチ更新がJDBCバッチ更新とは何の関係もないという事実から生じています。バッチ更新でHibernateが意味するのは、「バッチジョブによって実行される更新」です。バッチジョブは通常、通常のビジネスユースケースよりもはるかに長いトランザクションを持ち、1つのトランザクションで数百、数千、またはそれ以上のエンティティを更新します。この場合、メモリ不足を回避するために、Hibernateがセッションを定期的にフラッシュおよびクリアすることを推奨するのはこのためです。