0

JPAでの楽観的ロックの利点について少し混乱しています。

バージョン管理されたエンティティテーブルで2つのスレッドと1つの行を使用してテストを実行しました。
これが私が見つけたものです：

T1: begin tran
T1: fetch single entity
T1: Update field in entity
T1: sleep
T2: begin tran
T2: fetch single entity
T2: Update field in entity
T2: commit trans
T1: wake up
T1: commit trans - throws OptimisticLockException (expected)

2番目のテスト。selectステートメントが追加されていることに注意してください。

T1: begin tran
T1: fetch single entity
T1: Update field in entity
T1: run select query on table (this causes a DB transaction to begin)
T1: sleep
T2: begin tran
T2: fetch single entity (this blocks until DB transaction of thread T1 completes!)
T2: Update field in entity
T2: commit trans
T1: wake up
T1: commit trans - ok, no exception. The fetch/update/commit of T2 happened after T1 commit.

楽観的ロックを使用するときにブロッキングが発生することは実際には予想していませんでしたが、selectステートメントから正しいデータが返されるように、ここでデータベーストランザクションを実行する必要があることを理解しています。
JPAは絶対に必要な場合にのみデータベーストランザクションを入力するように見えるので、楽観的ロックの利点を誰かが説明できますか？

4

1 に答える 1

1

最初の例では、JPAが更新を完全に必要とするまで更新を保留していることは正しいですflush。2番目の例では、selectが最新のデータを処理するように、それらをフラッシュする必要があります。

楽観的ロックの利点の1つは、データベースがテーブルをロックする必要がないことです。これにより、より多くのクライアントがデータベースに対してステートメントを発行できるため、データベースの拡張性が向上します。欠点は、その同時実行制御の多くがアプリケーション層に移動することです。

これは、エラー処理または再試行ロジックを実装する必要があることを意味します。論争のある更新がないと予想される場合、これは良いことです。多くのクライアントが同じJPAエンティティを同時に更新することが予想される場合、エラーを処理し、「last-write-wins」の状況に頼ることなく更新をインテリジェントに再試行するために、かなりの量のアプリケーションロジックが必要になる可能性があります。

このブログ投稿は興味深いものですhttps://blogs.oracle.com/carolmcdonald/entry/jpa_2_0_concurrency_and

于 2013-02-11T23:53:38.007 に答える