web-dev-qa-db-ja.com

デフォルトでHibernateの楽観的ロック

Hibernateでの楽観的ロックについて1つ質問があります。私はHibernateを使用して楽観的ロックの内部に深く入り込もうとしていますが、疑問が1つあります。 Hibernateはバージョンアプローチ（整数またはタイムスタンプ）を使用して楽観的ロックを実装します。構成するには、@ Versionアノテーション（またはxml構成）を使用してバージョン属性を作成できます。もう1つのオプションは、optimistic-lock = "all"属性を使用してバージョン管理せずに構成することです。

私の質問は、バージョニング属性を定義せず、またoptimistic-lock属性を指定しない場合です。この場合、どの戦略がHibernateを使用しますか？ Pessimistc Lockingいいえ、私はかなり確信しているので、それは楽観的ロックだと思いますが、方法がわかりません。

ご清聴ありがとうございました。

hibernateoptimistic-locking
16
lordofthejars

楽観的ロックを使用するようにHibernateを構成しない場合、ロックはまったく使用されません。したがって、この場合、最後の更新が常に優先されます。

明確にするために、Hibernateの楽観的ロックはDBMSトランザクション分離とは完全に異なることに注意してください。 Hibernateの楽観的ロックは、あるトランザクションでオブジェクトをロードし、それを変更して、後で別のトランザクションに保存する場合にのみ機能します。この場合、楽観的ロックにより、他のトランザクションがデータベース内のそのオブジェクトをその間に変更していないことが保証されます。ただし、楽観的ロックは同時トランザクションの分離に影響を与えません。したがって、DBMSがトランザクション分離を実装するために内部で使用するロック（楽観的または悲観的）は、休止状態ロックが有効かどうかに関係なく機能します。

44
axtavt

@axtavt、その通りですが、hibernateが@Version列なしで楽観的ロックを実装する方法について質問します。

今日利用可能な4つのOptimisticLockTypeオプション：

/**
 * Perform no optimistic locking.
 */
NONE,
/**
 * Perform optimistic locking using a dedicated version column.
 *
 * @see javax.persistence.Version
 */
VERSION,
/**
 * Perform optimistic locking based on *dirty* fields as part of an expanded WHERE clause restriction for the
 * UPDATE/DELETE SQL statement.
 */
DIRTY,
/**
 * Perform optimistic locking based on *all* fields as part of an expanded WHERE clause restriction for the
 * UPDATE/DELETE SQL statement.
 */
ALL

元の質問に答えるにはこれで十分だと思います。

4
Ruslan