- ベストアンサー
SELECT FOR UPDATEについての質問
- SELECT FOR UPDATEを使用すべきか
- SELECT FOR UPDATEのロック期間
- SELECT FOR UPDATEの挙動
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
#1回答者です。 #1回答にも書いたように、排他制御はRDBMSにより仕様差があります。一方で様々なオプションがあり、似たような制御にすることも可能です。 MySQLでも、ストレージエンジンの種類で排他単位が変わったり、排他制御の強さや区間を変える様々なオプションがあります。 MySQLについて調べてみました。 >複数のプログラムで在庫の更新などが行われる場合に、 >使用するべきでしょうか? 複数のユーザが接続する環境で、関連する複数の表、あるいは複数の行を検索、更新する場合に使います。 >SELECT FOR UPDATEのロック期間は、他の更新が待たされるのは >下記2.~3.の間でしょうか? FOR UPDATE指定でSELECT実行~トランザクション終了までです。 >上記2.のSELECT FOR UPDATEがおこなれた時点のレコードに対し、 >他の場所でSELECT FOR UPDATEした場合、 >上記2.の時点のデータがSELECTされるのでしょうか? >それとも、上記3.が終わるまでSELECTを待つのでしょうか? FOR UPDATE同士の検索が複数ユーザからあると、先に検索した側がその行を占有するため、後続ユーザは排他待ちになります。待ち解除されるのは、先行ユーザがCOMMITしてくれた時点です。 マニュアル参照先 http://dev.mysql.com/doc/refman/4.1/ja/commit.html http://dev.mysql.com/doc/refman/4.1/ja/innodb-locks-set.html http://dev.mysql.com/doc/refman/4.1/ja/innodb-transaction-model.html
その他の回答 (1)
- chukenkenkou
- ベストアンサー率43% (833/1926)
>DBは、MySQL5ですが、DB問わず同じ挙動と思い、 >このカテゴリに質問されていただきました 排他制御の挙動は、RDBMS毎に相当な違いがあります。 MySQLについて知りたいなら、MySQLのカテゴリで質問してください。
お礼
マニュアルの参照先までありがとうございます。 MySQLコマンドを2つ起動して、 やってみたところ、排他待ちになりました。 制御はRDBMSにより仕様差が結構あるのですね。。 1.BEGIN 2.処理 3.BEGIN でもコミットされてしまいました。 とりあえずファイルロックで逃げる事にしましたが、 ロックはなかなか奥が深く難しいですね。 DBを変えたら試行錯誤が必要と感じました。