河野真治 @ 琉球大学情報工学です。(Oracle の話?)

In article <bq29jh$7m1$1@news-wst.ocn.ad.jp>, Tanaka-Qtaro-Yasuhiro <tanaq@ca2.so-net.ne.jp> writes
> データベースの処理を作るときに、「トランザクションで囲んでおきさえ
> すれば、ACID特性はしっかり守られて問題ナシ」とか思って作っていたら、

新城さん方式ね。

> isolation levelが READ COMMITEDだったので、処理を全部見直す必要が
> 出てきた、とまあそんなところです。

あぁ。なるほど。

ACID ってのは、Atomicity, Consistency, Isolation, Durability の
ACID なのね。これらは自分で選択するものですよね。

> 副問い合わせで最大値とって結合してたり、でもってその結果で削除する
> 行を決めてたりとか、複雑な処理だとこんがらがっちゃうんですね。

確かにそうですね。
    副問い合わせで最大値とって結合してたり
のあたりは実はどれをとるかは正確である必要はなくて、一方で、
    削除の前後で、データベースの正確さは維持したい
みたいな場合もありますよね。

あるいは、
    削除によって、データベース中の最大値の性質を維持したい
みたいな場合もあると思います。前者だと、それぞれを二つ別なト
ランザクションにしても良くて、後者では一つにしないとだめです。

> やばそうな処理をするときだけ、ISOLATION LEVELを上げるというのも手な
> んだろうけど。

どっちかっていうと逆でデータベースでなんらかの性質を維持した
いのならば、全部SERIALIZEでないとだめです。「データベースに
は変更を加えないことがわかっている」とか「不正確なデータでも
いいから速くとりたい」ような場合に、ISOLATION LEVELを下げる
ってことじゃないかな。

「性能が下がりそうなところを下げる」ってことなんだと思います。
おそらくは、ISOLATION LEVELで lockの種類を決めているんでしょ
う。Shared lock しかかけないとかさ。

しょせん、実装を知らないでいじっても、結局は混乱するだけって
いうことなんじゃないかなぁ。

---
Shinji KONO @ Information Engineering, University of the Ryukyus, 
河野真治 @ 琉球大学工学部情報工学科,