山本です。

松枝さんはこれ以上スレッドを伸ばすおつもりが無いようですが、
ネタを振られたのでもう少しおつき合い願えますか。

「どのような実装があるか」という私の問いに対して教えて頂いた MSDE で検
証を行っていますが、私の予想とは異なる挙動になっています。ですが 
MSDE(SQL server) は詳しくなく、ODBC 経由で autocommit=0 状態にするのも 
web を漁らねばならぬ程度の知識なので、自身の検証結果に自信がありません。

端末1 と 端末2 の例に戻ります。
REPEATABLE READ で autocommit=0 です。

松枝さんが望む挙動は、「端末1 で commit された結果が時系列で直後の端末
2 の select の結果に反映する」と理解しました。(上記の私の予想がこの動
作です) 
InnoDB では、「端末2 で commit しなければ端末2 の select に反映されず、
挙動が正しくない」と理解しました。

私の検証では松枝さんの望む挙動が再現できず、また InnoDB と MSDE の挙動
も異なりました。松枝さんのお話しと MSDE, InnoDB の挙動といずれが正しい
か判断できません。みなさんの検証ではいかがでしょうか。
(MSDEでの私の検証結果の詳細はさしあたって伏せておきます)

参考までに MSDE 用に用意した SQL です。
term* :: が、それぞれの端末で発行する SQL です。

create database TEST
create table BBB ( ID int)

term1 :: delete from BBB
term1 :: insert into BBB values (1)
term1 :: set transaction isolation level repeatable read
term1 :: set implicit_transactions on
term2 :: set transaction isolation level repeatable read
term2 :: set implicit_transactions on
term1 :: select * from BBB
term2 :: select * from BBB
term1 :: update BBB set ID=2 where ID=1
term2 :: select * from BBB
term1 :: commit
term2 :: select * from BBB
term1 :: select * from BBB

# 余談ですが石野さんが firebird の例を挙げられましたが、これは私が
# 他の RDBMS ではどうか、という意味の話題を振った為でしょう。
# 多数決などで決めようといった意味は無いと思います。

----
Hideki Yamamoto
kuyo@xxxxxxxxxx


At Thu, 12 Aug 2004 10:30:19 +0900,
ML account wrote:
> 
> 　こんにちは。
> 
> EBIHARA Yuichiro <uiebi@xxxxxxxxxx>さんの
> <20040811065327.90892.qmail@xxxxxxxxxx>
> "[mysql 10000] Re: データのロックについて"
> 
> 　お、キリ番ですね。（笑）
> 
> > > 　ある接続がイン・トランザクションであるとして、そのトランザクションに
> > > 対して重大な影響を与える他の接続での操作を許してしまうのは、一体どうい
> > > う事なんでしょうね。「トランザクションが暗黙的に終了します」は、その影
> > > 響を喰らう他の接続のトランザクションも、と言う事ですか？（笑）
> > 
> > これは、例えばテーブルAをUpdateしているトランザクションXがあったときに、
> > 別のトランザクションYがテーブルAをDropしたら、トランザクションXも暗黙的に
> > 終了してしまうの?　という疑問でしょうか?
> > 
> > MySQLがどうかは知りませんが、普通はトランザクションXはテーブルAそのものに
> > 対して共有ロックを取得するから、トランザクションYはDROP TABLE文でロック待
> > ちになるもんなんじゃないでしょうか。
> 
> 　そう、ロックで待ちになる、が正解と言うか、ボクが期待するだろう動作です
> ね。ボクが想定していたのは、片方がselect、もう片方がrenameです。
> 
> 　REPEATABLE READ分離レベルは「イン・トランザクションでの複数のselectが
> 同じ結果を返す」ですが、「他のプロセス/トランザクションによって、
> selectされた結果が変更される事は無い」と説明されている場合もありますね。
> となると、 REPEATABLE READ分離レベルは共有ロックで実現される事が実はキモ
> だったりするのかもしれません。
> 
> 
> > > 　REPEATABLE READ分離レベルのイン・トランザクションで REPEATABLE
> > > READが保証されない場合がある事、これは結構重大ですね。本来あってはなら
> > > ない事ですから。ダーティリードと逆のコミットされているデータが読めな
> > > い、selectの結果を信じて出したupdate等が実はスカになってしまう、などと
> > > 言う珍妙な事も起こりますね。REPEATABLEREAD分離レベルの動作としては、
> > > 「コミットされたデータ」の存在自体がかなり異様でしょう。
> > 
> > この一節がよく分からなかったので補足していただけるとうれしいのですが、MySQL
> > のどの現象を指してREPEATABLE READ分離レベルを指定してもREPEATABLE READに
> > ならないとおっしゃっているのでしょうか。
> > それともマニュアルにそう読める部分があるということですか。
> 
> 　「REPEATABLE READが保証されない」は[mysql 10005]のとみたさんの試行です。
> 「ダーティリードと逆の」は、ボクのREPEATABLE READ分離レベルでの挙動に対
> する元々の疑問ですし(常にイン・トランザクションと言うのは意外でしたが)、
> また [mysql 09992]で池原さんが述べられている疑問です。「update等が実はス
> カ」もそれのバリエーションですね。
> 
> 　同じ事の繰り返しになってしまいますが、REPEATABLE READ分離レベルは共有
> ロックで実現する事が重要なのでしょう。そうであれば「コミットされたデータ」、
> ある接続でのselect対象に他の接続がupdateを掛けコミットする、の様な事は端
> から起こらない訳で。単純に「同じ結果」を追求するあまり、「じゃあスナップ
> ショット」が、実際あれれなのかとも思います。
> 
> −−−
> 
> 　MySQL/InnoDBは、ロストアップデートが起こっている気がしますし(以前述べ
> た様に再現は出来ませんでしたが)、トランザクションの動きに関して微妙に (
> 盛大に？)イヤな所がある、の印象を持っています。
> 
> 　まあしかし、「MySQLの真価はトランザクションのサポートでは無い、その高
> 速性にある」は持論ですから、トランザクションが使える使えないはボク的には
> 些末な事ですね。Oracleやその他のデコレーテッドDBMSにあってMySQLに無い(無
> かった)機能は、トランザクション、サブクエリ、ストアードプロセジャ、トリ
> ガ、スキーマ等ですが、この中でボクが一番欲しいのはサブクエリ (アトミック
> でないと困りますけど)、その次はストアードプロセジャですね。トランザクシ
> ョン、トリガ、スキーマは、ボク的にはMySQLに要らなかったりします。
> 
> 　しかし些末な事なのにも関わらず、何でここまでこのスレッドが伸びてしまっ
> たのかは、考えるに感覚の相違なのでしょうか。ボクがある事を些末と考える事
> と、その些末な事が妥当であるかどうかや、妥当な根拠で妥当と言っているのか
> 否かは、ボク的には別の事だったりします。
> 
> 
> 　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
> 　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/
> 
> 
>