flush() メソッドについての情報を収集していましたが、いつ使用すればいいのか、またどのように正しく使用すればいいのかがよくわかりません。私が読んだところによると、永続コンテキストの内容はデータベースと同期される、つまり、未処理のステートメントを発行したり、エンティティ データを更新したりするものだと理解しています。
ここで、2 つのエンティティとA( B1 対 1 の関係ですが、JPA によって強制またはモデル化されていません) がある次のシナリオがあります。にはA、手動で設定された複合 PK があり、自動生成された IDENTITY フィールドもありますrecordId。 これは、 への外部キーとしてrecordIdエンティティに書き込まれる必要があります。と を単一のトランザクションに保存しています。 問題は、 を呼び出した後で を明示的に呼び出さない限り、自動生成された値がトランザクション内で使用できないことです。 (自動生成された IDENTITY PK がある場合、値はエンティティ内で直接更新されますが、ここではそうではありません。)BAABA.recordIdem.flush()em.persist()A
em.flush()トランザクション内で使用すると、何らかの害を及ぼす可能性がありますか?
ベストアンサー1
の正確な詳細はおそらくem.flush()実装に依存します。いずれにせよ、一般的には、Hibernate などの JPA プロバイダーは、データベースに送信することになっている SQL 命令を、多くの場合、実際にトランザクションをコミットするまでキャッシュできます。たとえば、 を呼び出すとem.persist()、Hibernate はデータベース INSERT を実行する必要があることを記憶しますが、トランザクションをコミットするまでは実際に命令を実行しません。私の知る限り、これは主にパフォーマンス上の理由で行われます。
いずれにしても、SQL 命令をすぐに実行したい場合があります。一般的には、自動生成されたキーやデータベース トリガーなどの副作用の結果が必要な場合です。
em.flush()内部 SQL 命令キャッシュを空にして、データベースに対してすぐに実行します。
結論: 害はありませんが、SQL 命令をデータベースに送信する最適なタイミングに関する JPA プロバイダーの決定をオーバーライドするため、(軽微な)パフォーマンスの低下が発生する可能性があります。