アンラップされた接続によってJPAコミットの変更が行われる

Question

汚れたオブジェクトを含まないエンティティ・マネージャからトランザクションをコミットするとどうなりますか？ COMMITコマンドがDBに送信されないことはありますか？

私はいくつかのテストケースが今や失敗していて、合理的な理由がないままでした。いくつかの調査の後、ここで私がここで確認したい理論があります。

私は小さなテストフレームワークを持っており、各テストのDB上のデータを準備しています。固定具は、JPA（休止状態）を使用してDBにオブジェクトを格納するような方法を使用します。したがって

public <R> R doInTransaction(final Function<EntityManager, R> whatToDo) { 
    final EntityManager em = emf.createEntityManager(); 
    final R result; 
    try { 
     try { 
     em.getTransaction().begin(); 
     result = whatToDo.apply(em); 
     em.getTransaction().commit(); 
     } finally { 
     if (em.getTransaction().isActive()) { 
      em.getTransaction().rollback(); 
     } 
     } 
    } finally { 
     em.close(); 
    } 
    return result; 
    } 

を、固定具は、オブジェクトが永続化さwhatToDo関数を渡し、このメソッドを呼び出し、メソッドは、渡された関数の周りにトランザクションをラップ。失敗したテストケースでは、ストアドプロシージャを使用するレガシーコードに依存するフィクスチャを使用し、JDBCを介してオブジェクトを直接格納しています。 e。によって管理されるいかなるJPA済オブジェクトが存在しないように、私の理論は、JPAは、このような状況ですぐにコミットされていないということです

em.unwrap(Session.class).doWork(connection -> { 
    // stored procedures are called here directly over JDBC 
}); 

：代わりにem.persist()を使用して、私はストアドプロシージャを呼び出すために渡された関数で次のように使用しますEntityManager。その結果、実際のコミットは後でのみ発生します。 e。私のテストの主張の後に、テストは失敗します。それは可能性が？

EntityManagerから接続を「アンラッピングする」ときのHibernateのトランザクション動作は何ですか？

em.getTransaction().commit()の前にem.flush()を追加しましたが、これは役に立ったようですが、これが問題を解決するとはまだ100％自信がありません。誰かが確認できますか？

Answer 1

接続のアンラッピングに関係なく動作は同じです。 JTAを使用していない場合は、JDBCが提供する基本トランザクション、つまりローカルトランザクションです。

接続をアンラップしてJDBCを直接処理すると、このセッション/エンティティマネージャによって最初に取得された接続と同じ接続が得られます。だから同じ効果です。