楽観的ロック

っていうか楽観的同時実行制御といった方がいいかな．ロックをかけないで楽観的に行きましょうという気持ちなので．

■ [DB] 楽観的ロックはダーティリードと合う？（間違い）
Read CommittedでVersionNo排他による楽観的ロックの場合、
トランザクションAがレコードaを更新して未コミットの時に、
トランザクションBがレコードaを更新しようとすると、
トランザクションAで更新されたVersionNoはトランザクションBでは取得されず、
どちらも排他されずに通ってしまう気がする。

と，それに対するひがさんのコメント．

# higayasuo 『Read CommittedだとBはロックでまたされます。』

真の「楽観的同時実行制御」だと待たされないはず．
ロックを使った擬似的 (実は悲観的) なやつだと待たされることになりますが．

本来の楽観的同時実行制御では，上のトランザクション A，Bともレコードを更新することが出来ます．互いに相手が更新した VersionNo を見ることはありません．marrow さんの書いたとおりです．
ただし，トランザクションをコミットできるのは片方だけで，もう片方は DBMS によりロールバックされます．マジです．
普通は競合することが滅多にないので，ロックをかけるコストよりもたまにロールバックするコストの方が少なくて効率的だという考え方が楽観的な同時実行制御なのです．RCS (悲観的) と CVS (楽観的) をイメージすればわかりやすいかな？実際，DBMS によっては競合したトランザクションをいきなりロールバックするのではなく，「マージ」するチャンスを与えてくれる製品もあったような気のせいが．
ともあれ (JW)，上記の話はあくまでも DBMS 自身が楽観的な同時実行制御をサポートしている場合にのみ通用する話であることに注意．GemStone など，ODBMS にはこの機能をサポートした製品がいくつかあったはずですが，RDBMS ではあまり見ないかな？

近年は楽観的ロックとかってよく見かけるようになりましたが，これは単一のトランザクションとして見るとロックを使った悲観的な同時実行制御なのだけれど，複数のトランザクションからなる全体としては楽観気味の同時実行制御を実現するという意味合いのことが多いようです．
本来の楽観的同時実行制御ではトランザクションのコミット時に成功するか失敗 (競合してロールバック) するかが決まるわけですが，似たようなことを (複数に分割されたトランザクションの) 最後のトランザクションでシミュレートする感じですね．
多少混乱気味の記事を見かけることもあるので注意しませう．