海老原です。

松枝さん、リプライどうもありがとうございます。

> (2) テーブルBBBのintフィールドIDに1が入っていて、
> 　　端末１："update BBB set ID=2 where ID=1"
> 　　端末１："commit"
> をAUTOCOMMIT=0で行った場合、端末１からselectで見るIDの値は２、端末２で
> 見る値は１の様に不整合が生じる場合がある。
> 
> 　今やった所、(1)は再現出来なかったのですが、(2)がWinで再現されてしま
> いました。どうすれば確実に再現出来るのかは、ちょっとわかりませんけど。
> selectの後に commitが必要な場合がある等、もう訳が分かりません。

[09953][09954]も拝見しましたが、Repeatable Readだから結果としては正しい結
果ですよね。
松枝さんが、SELECTでトランザクションが開始されてしまう点に違和感を感じる
のは分からなくはないですが、set autocommit=0 で暗黙的にトランザクションが
開始するということなんでしょう。

ちなみに当方ではOracleから来た人が戸惑わないよう、mysqld起動オプションで
  transaction-isolation=READ-COMMITTED
  autocommit=0
を設定の上で、基本的にInnoDBを使え、と言っています。(厳密には言う予定)

> 　 Webベースシステムでありがちな、同じIDで複数の接続を行う場合、テーブ
> ルロックは効きません。排他ロックでも、他の接続で読めちゃうし、書き込め
> ちゃいますね。 Oracle8.0.5、8iなWin/Solarisで確認。
> 
> 　Oracleでテーブルロックなんてあまり使わないでしょ？だからじゃないです
> か、聞いた事が無い、と言うのは。

読めちゃうのは当然ですけど、書き込めちゃうのは困りもんですね。
INSERT/UPDATE/DELETEは行ロックのほかに表ロックも獲得するはずですから。

> 　随分前の話ですけど、OracleMaster(Gold)な人がテーブルロックを使う設計
> をしてて、「それマズイよ」とちょいと言ったら「そんな馬鹿な話は無いです
> よ！ちゃんと動きます！」と凄い剣幕。で、実際に見せたら、ショックを受け
> たみたいですね。まあ、接続単位ではなくて接続ID単位でロックが有効にな
> る、ってだけの話でしょうが、 そのOracleMasterな人も接続ID単位でとは思
> っていなかったみたいですね。

僕もそれ見せられたら同様のショックを受けますね。
仕様的にはあり得ないので、もし本当ならバグだと思いますが、OracleのMLじゃ
ないので深く追究するのはやめにしておきます。

> > いわゆる楽観的ロックというやつですよね。
> > ただ、この場合にもトランザクションやロックによる排他制御が不要かと言
> > うとそんなことはなくて、単にロックを保持する期間を非常に短くできる、
> > という程度のことだと理解しています。
> 
> 　チェックと更新をアトミックな１クエリで出来るならば、ロックやトランザ
> クションは不要ですね。例えば、"update .... where CheckFld=[元の
> CheckFldの値 ]"の様な感じで。アトミック・トランザクションもトランザク
> ションでしょ！がご主張ならば、はぁ左様で、ですけど。

まあそういう主張です。
結局はUPDATE文の更新行数を見て、0行だったらエラーを返すのであれば、それは
楽観的ロックの実装がちょっと違うだけだと思いますんで。
そもそも更新が複数のテーブルにまたがることもありますし。

--
海老原 雄一郎