私は、Hibernateで楽観的なロックに関する1つの質問があります。私は、Hibernateを使って楽観的なロックを深くしようとしていますが、疑いがあります。 Hibernateは、バージョンアプローチ（整数またはタイムスタンプ）を使用して、オプティミスティックロックを実装します。設定するには、@ Versionアノテーション（またはxml設定）を使用してバージョン属性を作成することができます。もう1つのオプションは、optimistic-lock = "all"属性を使用してバージョニングなしで構成することです。デフォルトでは、Hibernateのオプティミスティックロック
私の質問は、バージョン管理属性を定義しないで、optimistic-lock属性を指定しない場合です。この場合、戦略はHibernateを使用しますか？ Pessimistc Locking私はそれほど確実ではないので、それは楽観的なロックだとは思いますが、方法はわかりません。
ありがとうございました。
オプティミスティックロックを使用するようにHibernateを設定しない場合、ロックはまったく使用されません。したがって、この場合、最終更新は常に勝ちます。
Hibernateのオプティミスティック・ロックは、DBMSトランザクションの分離とはまったく異なります。 Hibernateのオプティミスティックロックは、オブジェクトを1つのトランザクションにロードし、変更して後で別のトランザクションに保存する場合にのみ機能します。この場合、オプティミスティック・ロックは、他のトランザクションが間にデータベース内のそのオブジェクトを変更していないことを保証します。しかし、オプティミスティック・ロックは同時トランザクションの分離には影響しません。したがって、Hibernateロックが有効かどうかに関わらず、トランザクション分離を実装するために内部でDBMSが使用するロック（楽観的または悲観的）は依然として機能します。
@axtavt、あなたは正しいですが、@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
私は、これは元の質問に答えるには十分だと思います。