Re: Transaction isolation level
田中久太郎です。
Shinji KONOさんの<3989215news.pl@insigna.ie.u-ryukyu.ac.jp>から
>> 最近、データベースのトランザクション処理について、いろいろ考え
>> る機会があったのですが、自分自身かなりあやふやにしか理解できて
>> ないことがわかり、勉強しなおしたいと思っています。
>
>その「いろいろ考えた」ことが聞きたいなぁ...
いやあ、お恥ずかしい。
データベースの処理を作るときに、「トランザクションで囲んでおきさえ
すれば、ACID特性はしっかり守られて問題ナシ」とか思って作っていたら、
isolation levelが READ COMMITEDだったので、処理を全部見直す必要が
出てきた、とまあそんなところです。
副問い合わせで最大値とって結合してたり、でもってその結果で削除する
行を決めてたりとか、複雑な処理だとこんがらがっちゃうんですね。
で、トランザクション処理をうまく設計する定石とか基準みたいなものが
あるんじゃないかと思い、さきの質問を投げたわけです。
>トランザクションってのは、データベースへの処理の集合で、それを
>単位に、逐次に実行したのと同じなって欲しいものですよね。
そうなんです。どんなときでもそうなって欲しいんだけど、それが守られ
るのは、ISOLATION LEVELが SERIALIZABLEなときだけなんですよね。
やばそうな処理をするときだけ、ISOLATION LEVELを上げるというのも手な
んだろうけど。
>で、普通に、レコードを 2 phase lock してやって、dead lock を
>避けるために、複数のlockをかける時は、順序を全部同じにするよ
>うに心がけて... ぐらいでいいんじゃないですか? (僕の理解はそ
>の程度...)
そうか、あまり複雑に考える必要もなさそうですね。
基本的に処理中に触るデータには最初に全部順序良くロックする、と。
それで、効率とかトランザクションで保証されるところとかを考慮しなが
ら調整していく感じでしょうか。
>ロックの単位をテーブルにするかレコードにするか、あるいは、述
>語にするかを一般的に選択する基準は、僕は知りません。そんなも
>のはないのだと思います。
そういう基準は、めんどくささと効率とか比べながら、個々の場合で考え
ていくしかないんでしょうね。
>Date の Database System Concepts とかが教科書だけど...
和訳が無いかなと思って調べてみたんですけど、これがそうですかね?
http://www.amazon.co.jp/exec/obidos/ASIN/4621042769
うーん、高すぎて買えない…。図書館にあるかな。
--
Tanaka-Qtaro-Yasuhiro mailto:tanaq@ca2.so-net.ne.jp
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735