山本です。

この話題に関して、松枝さんの気分を害されない形で議論をする自信が私には
ありませんので、返答と私がこの議論で学んだことや思ったことを纏めたいと
思います。（逃げと受け止めて貰っても結構です）
私の発言に絡むことのみであり、他の方の議論をこのメールで全て纏めようと
いう意図ではありません。

やや冗長な文になってしまったので、興味のない方は読まれないことをお勧め
します。


・MSDE での検証結果の詳細を挙げなかったことについて

　そもそも私が「REPEATABLE READ の挙動に関して正しく実装されているプロ
  ダクトは何か」という質問をした意図は、希望する回答に「これこれがそう
  です」といった程度のものであり、自身で検証するにはどうしたらよいかで
  はありませんでした。

  自身での検証は本意ではなかったのですが、確かに MSDE は無料で入手でき、
  自分でも検証が出来るかと思い行ってみました。

  私にとって MSDE は理解が浅く検証手順が正しくない可能性があります。こ
  こで「この検証手順と結果は正しいのでしょうか？」といった質問をしてし
  まうと、MySQL ではなくMSDE 自体の話題になってしまう可能性があります。
  目的も MSDE の学習ではありませんし、「他の RDBMS の話は余所でやって
  欲しい」と言われれば反論できませんので、あえて結果を挙げませんでした。

・implicit_transactions を on にした理由

  MySQL での set autocommit=0 となるべく同じ条件で検証したかったからで
  す。
  http://www.microsoft.com/japan/SQL/evaluation/compare/fororacle/SQLserver_02_Chap5_01.asp
  (URLなので改行なしです)
  これを夾雑とは捉えておりません。


・検証結果について

  過去の投稿メールから引用します。

  [mysql 09975]より
  >> repeatable readは、同一トランザクションにおいて、複数回の
  >> selectコマンドが発行された場合、選択されたレコードが他の
  >> トランザクションの影響を受けない「分離性」です。
  >>
  >> なので、松枝知直さんが提示された以下の例では、
  >>
  >>      term1                           | term2
  >>     ---------------------------------+--------------------
  >>      set autocommit=0;               |
  >>                                      | set autocommit=0;
  >>      select * from BBB;              |
  >>                                      | select * from BBB;
  >>      update BBB set ID=2 where ID=1; |
  >>                                      | select * from BBB;
  >>      commit;                         |
  >>                                      | select * from BBB;
  >>      select * from BBB;              |
  >>
  >> term1でcommitを発行してレコード更新を確定したとしても、
  >> term2のトランザクションは続いたままなので、repeatable r
  >> eadの分離性のために、term2の3つのselectコマンドは全て
  >> 同じ結果になります。
  >>
  >> term2が、term1での更新結果を取り込むには、term2のトラ
  >> ンザクションを終了させる必要があります。(たとえば、commit
  >> コマンドなどで)
  >> とみたまさひろさんが、「..常にイン・トランザクション,,,」といった
  >> のは、こういう意味じゃないでしょうか。
  >
  >　接続２(term2)がイン・トランザクションであれば、その通りでしょうね。で
  >も、akiraさんの論理は少々のmissing linkと言うか、飛躍があるのです。接続
  >２(term2)がイン・トランザクションである事を、証明不要な事実と仮定(じゃな
  >くて断定、かな？)していませんか？
  >

  [mysql 10013] の検証は明示的にトランザクションを開始しているので、
  MySQL における set autocommit=0 の状態と異なっていますね。

  また、akira さんの返答に対し「イン・トランザクションであれば…」と同
  意していますが [mysql 10013] の結果は、

  「明示的にトランザクションを開始しており他のトランザクションの影響を
  受けずトランザクション中の select の結果が一貫しているものの、ロック
  によって [mysql 09975] と同じ手順で SQL 発行を行うことが出来ない」

  ことを表していると理解しました。

  [mysql 10013] では [mysql 09975] 及び 例の元となった [mysql 09953] 
  の説明には不十分であると思いました。MSDE の挙動を元にするならば、
  「ここでロックが発生し一貫性を保つはずなのにロックが発生しないのはお
  かしい」などの指摘になると考えます。


まとめとして、私が今までの議論で得た見地を挙げます。

・REPEATABLE READ で set autocommit=0 での MySQL の挙動
  トランザクション中は他のトランザクションの影響によって select
  ... from ... の結果が変わる事はない。なぜならばトランザクション開始
  後、select ... from ... 発行時にその時点のスナップショットが作成され、
  結果はスナップショットから取得されるからである。

・同条件での MSDE の挙動
  トランザクション中は他のトランザクションの影響によって select
  ... from ... の結果が変わる事はない。なぜならばトランザクション開始
  後、select ... from ... の結果は確定されたデータを必ず返すからである。
  データが確定できない場合は、確定できるまでトランザクションの進行はロッ
  クされる。

・SQL92 や MySQL, 他の RDBMS においても MySQL での set autocommit=0 状
  態では select ステートメントでトランザクションが開始され、明示的にト
  ランザクションを終了するまで終了しない。
  (これを否定する根拠が見当たらなかったため)

・分離レベルの概念は ANSI などで定義されているが、その実装は RDBMS に
  よって異なる場合がある。実装が異なると見た目の挙動も変わるが、どちら
  が正解とは単純に言うことは出来ない。
  (今回の MySQL と MSDE の挙動の違い、他の例として
    http://www.oracle.co.jp/2shin/2002/ora51/20.html
  など)

・MySQL, MSDE では同じ分離レベルでも実装モデルや挙動が異なるので、それ
  ぞれの特性をよく理解し、混同しないようにすべきである。

  おまけですが、MySQL ではロックを獲得する SQL ステートメントに drop 
  は含まれないようです。drop するときには気をつけねば。
  http://dev.mysql.com/doc/mysql/ja/InnoDB_Locks_set.html


長々と書いてしまいました。最後まで読んでくれた方には慰労の意を表したい
ところです。
いままで余り係わってこなかったトランザクションについて、一定の知識を得
られたので大いに収穫がありました。またよく聞く「デッドロックで云々」は、
RDBMS によっては容易に起こりうる事だったのですね。MySQL のみの知識では
理解できなかったでしょう。

それでは。

----
Hideki Yamamoto
kuyo@xxxxxxxxxx