Path: ccsf.homeunix.org!ccsf.homeunix.org!news1.wakwak.com!nf1.xephion.ne.jp!onion.ish.org!onodera-news!newsfeed.media.kyoto-u.ac.jp!cancer.nca5.ad.jp!hakata!ie.u-ryukyu.ac.jp!u-ryukyu.ac.jp!ie.u-ryukyu.ac.jp!not-for-mail From: kono@ie.u-ryukyu.ac.jp (Shinji KONO) Newsgroups: fj.comp.databases Subject: Re: Transaction isolation level Date: 26 Nov 2003 14:22:20 GMT Organization: Information Engineering, University of the Ryukyus Lines: 49 Message-ID: <3989220news.pl@insigna.ie.u-ryukyu.ac.jp> References: <3989215news.pl@insigna.ie.u-ryukyu.ac.jp> NNTP-Posting-Host: insigna.ie.u-ryukyu.ac.jp Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Image-URL: http://www.ie.u-ryukyu.ac.jp/~kono/skono.gif Fcc: send X-Newsreader: news.pl,v 1.11 2003/10/08 11:51:01 Content-ID: <4556.1069856540.1@insigna.ie.u-ryukyu.ac.jp> Xref: ccsf.homeunix.org fj.comp.databases:22 河野真治 @ 琉球大学情報工学です。(Oracle の話?) In article , Tanaka-Qtaro-Yasuhiro 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, 河野真治 @ 琉球大学工学部情報工学科,