Hibernate：LockOptions.UPGRADEでget（）の後にオブジェクトをリロードしますか

Question

メソッドを使用してLockOptions.UPGRADEを使用して行のロックを取得する問題に直面しています。

ロックが取得されているオブジェクトは、すでにセッションに存在しています。 select ...を実行すると、テーブルの対応する行がオブジェクトの最初のフェッチの後で、get(Serializable,Class,LockOptions)の前に変更された場合、メソッドは更新されたオブジェクトを返さないことを確認しています。

私は次のことを明確にしたいと思います。 これは、オブジェクトがすでにセッションキャッシュにロードされている行のロックを取得しようとしているためです。

Hibernateはバックグラウンドでselect ... for updateを起動しますが、オブジェクトをリロードしませんが、見つかった場合はセッションキャッシュから1つをフェッチしますか？

以下は、私がどのようにロックを取得しているかのコードスニペットです。

List<MyObject> listOfMyObject = dao.getListOfMyObjects(); 

for(MyObject m : listOfMyObject){ 
    m = session.get(id,MyObject.class,LockOptions.UPGRADE); 
    // 
} 

ロック機構が正常に動作しています。ロックが保持されている間、ThreadOneトランザクションを実行すると、他のThreadTwoトランザクションがロックの獲得を待っていることがわかります。今度は、ThreadOneトランザクションがロックを解放すると、2番目のトランザクションはsession.get(id,MyObject.class,LockOptions.UPGRADE)メソッドを使用して取得します。返されるオブジェクトには、ThreadOneによって更新された値がありません。

Answer 1

理想的には、LockOptions.Upgradeを使用している場合、一種の悲観的なロックです。

理想的には、そのデータベース行の一種の悲観的なロックであるため、他のトランザクションが来てレコードを変更することはできません。

理想的には、悲観的なロックを使用する代わりに、プログラマチックにより多くの制御がある種類のバージョン/タイムスタンプ列を使用してオプティミスティックロックに進みます。

Answer 2

はい、Hibernate docsによると、session.get(Serializable,Class,LockOptions)は、すでに存在する場合はセッションからインスタンスをロードします。状況に応じて、session.get(Serializable,Class,LockOptions)の直後にsession.refresh(Object object)を使用して、データベースからインスタンスの状態を再読み込みすることをお勧めします。