21

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

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

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

4

2 に答える 2

48

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

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

于 2012-04-12T08:26:33.500 に答える
4

@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

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

于 2015-01-31T22:53:14.033 に答える