2017-11-02 4 views
0

以下は、私が楽観的なロックを取得するために使用しているコードスニペットです。エンティティ内のデータを更新せずにオプティミスティックロックを取得する

setting = this.entityManager.find(Setting.class, id, LockModeType.OPTIMISTIC_FORCE_INCREMENT); 
setting.setUpdateTimestamp(new Date()); // I want to make sure that this setting is not changed by 
//any other module. So I am updating timestamp so that others will fail. 
newSettingList.add(setting); 

さて、エンティティ内のフィールドのいずれかを更新せずにこれを行うと楽観的ロックでその実体がない他のモジュールの変更を確認するために、他の方法があります。

+0

同じデータに対して2つ以上のプロセスアクセスが同時に発生し、同時に変更しようとすると、楽観的ロックが発生します。複数のプロセスが同じデータを変更しているかどうかチェックしましたか? – Anil

+0

はい。同じ設定データを変更できる並行処理があります。 – Vrishank

+0

optimistic_force_increment単独では、ロックプロセスがコミットするまでデータが他のプロセスによって変更されないことを保証しますか?または更新ステートメントが必要ですか? – Vrishank

答えて

0

optimistic_force_increment単独では、ロックプロセスがコミットするまでデータが他のプロセスによって変更されないようにしていますか?

あなたはそれが何を意味するかによって異なります。 そのエンティティに楽観的なロックをかけます。 これは、定義すると、他の人が自由に変更できることを意味します。変更する前に変更をフラッシュすると、データベースに書き戻すことさえできます。 これを行うと、変更をフラッシュしようとすると例外が発生します。

前にフラッシュすると、例外が発生します。

コミットまたはロールバックする前に誰かがエンティティを書き込まないようにするには、悲観的なロックが必要です。反復に関して

は楽観的ロックは、以下の保証(JPA仕様から引用)を得読み出す:

P2(非反復可能読み取り):トランザクションT1は、行を読み取ります。別のトランザクションT2は、T1がコミットする前に、その行を変更または削除します。両方のトランザクションは最終的に正常にコミットされます

トランザクションコミットが行われるまですべてが許可されることに注意してください。

悲観的ロックは、この保証を与える:

P2(非反復可能読み取り):トランザクションT1は、行を読み取ります。別のトランザクションT2は、T1がコミットまたはロールバックされる前に、その行を変更または削除します。

したがって、T1(ロックを保持しているもの)が完了する前に、T2は変更を行うことができません。

更新文が必要ですか?

明示的に更新する必要はありません。しかし、バージョン番号の*FORCE_INCREMENTロックタイプにはアップデートが含まれています。したがって、データベースへの往復が含まれます。

注:例外が通常発生すると思うので、私はいつも "フラッシュ"を書いていますが、仕様ではJPAの実装がそのように感じられるたびにそのことが可能です。

関連する問題