データベースプログラミング全般スレ

**デフォルトの名無しさん** · NG

データベース板もあるが、あそこは過疎板だからこっちに立てました。
データベース関連のプログラミングならな～んでもOK。
色んな話をしませまうる号。

**デフォルャgの名無しさん** · 2016/09/07(水) 03:09:09.50

うは、なんか文字化けしとる
MySqlのロック周りについて詳しい解説サイト教えてくれ
と書いたんだが、さて

**デフォルトの名無しさん** · 2016/09/07(水) 10:18:08.32

>>500
まず、俺がトランザクションについて理解していないとか、分離レベルについて理解していないとか、
そういう思い込みを捨てろ。俺に言わせれば、お前の方が理解していないように見えるんだが。

> MySQLどうこうじゃなくて、SERIALIZABLEを正しく実装してる全てのDBMSで正しく動作するけど？
いや、serializableなトランザクションに関する各RDBMSの実装が異なっているというのが前提で、
だからこそ「serializableなトランザクションを使えばうまくいく」という一般論にはならない。
なので、「MySQLならこういう限定条件であればserializableなトランザクションを使えば良い」という
ようにしか言えない。

> >>477がちょっと気になったんだが
> 本当に先行トランザクションのuser1のinsertがブロックされたり
> user2が(ロックタイムアウトじゃなくて)デッドロックで落ちたりするのか？
いやいや、実行結果って書いたじゃん。実際に自分でもやってみたら？

> それがホントなら誰かMySqlのロック周りについて詳しい解説サイト教えてくれ
「mysql serializable」でググった1ページ目には、その「詳しい解説」は見つからなかったのか？

**デフォルトの名無しさん** · 2016/09/07(水) 10:40:31.01

PostgreSQLでもやってみた。

user1: begin transaction isolation level serializable;
user1: select count(*) from t where a=3; -> データがないことを確認できる
user2: set tx_isolation = serializable;
user2: begin transaction isolation level serializable;
user2: select count(*) from t where a=4; -> データがないことを確認できる
user1: insert into t values(3, 300); -> insertは完了する
user2: insert into t values(4, 400); -> insertは完了する
user1: select count(*) from t; -> 1
user2: select count(*) from t; -> 1
user1: commit; -> 成功する
user2: commit; -> エラー発生
> ERROR: トランザクション間で read/write の依存性があったため、アクセスの直列化ができませんでした
> DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
> HINT: リトライが行われた場合、このトランザクションは成功するかもしれません

**デフォルトの名無しさん** · 2016/09/07(水) 10:42:56.92

各RDBMSがserializableなトランザクションの実装で保証するのは「ファントムリードがないこと」であって、
それを実現する方法は各RDBMSの実装にまかされている。

**デフォルトの名無しさん** · 2016/09/07(水) 10:43:58.68

訂正：
>>505の
> user2: set tx_isolation = serializable;
は削除し忘れ。

**デフォルトの名無しさん** · 2016/09/07(水) 11:58:09.82

少し解説を加えると、RDBMSはserializableなトランザクション内の文脈を見て成功・失敗を決めているわけではなく、
ただ単にファントムリードが発生しないような実装にしているだけ。

あと、ロックと処理がブロックするというのは別の話。
ファントムリードを防ぐという目的の場合に、read lock対read lockなら処理はブロックしないという実装もありだし、
read lock対read lockでも処理をブロックするという実装もありえる。

またserializableなトランザクションの場合、リトライすればOKな場合がある。
そもそも、トランザクションが重ならなければお互いOKになる場合ね。
そういうケースでは、SQL CODEの内容からリトライ可能かどうかを判定してリトライするという実装が必要。
もちろん1回だけのリトライではまた他のトランザクションと重なる場合があるので、MAX回数を決めてリトライを
続ける必要がある。

そういう面倒くさいことをしてまでも、ファントムリードを防がなければならないケースに限って、トランザクションを
serializableにするというのが正しい使いだと思う。
ユニーク性を担保したいだけだったら、テーブルロックで十分。

**デフォルトの名無しさん** · 2016/09/07(水) 15:28:03.69

テーブルロックは常に成功するとでも思ってるんだろうか

**デフォルトの名無しさん** · 2016/09/07(水) 15:44:40.75

>>509
デッドロックになるようなロックのかけ方すればエラーになるだろうけど、それと今回の話とは関係ないよね。

**デフォルトの名無しさん** · 2016/09/07(水) 19:16:59.25

デッドロックとロックタイムアウトの区別もつかない人か

まあserializableで単独テーブルに対するアクセスでデッドロックするのもどうなんだという感じがしないでもないが
それでも少なくとも2重登録の防止って要件はserializableで満たしてるわけだが

同時実行する他のトランザクションがエラーになるのはダメとか、それは分離レベルが保証することではないし
リトライすればOKな事もあるとか、もはや分離レベル関係ないし

**デフォルトの名無しさん** · 2016/09/07(水) 22:23:54.80

>いや、serializableなトランザクションに関する各RDBMSの実装が異なっているというのが前提で、
>だからこそ「serializableなトランザクションを使えばうまくいく」という一般論にはならない。

この時点で理解してないのは明らか。そもそもSERIALIZABLEは無条件に直列化可能で
あることを保証するものだし。

>各RDBMSがserializableなトランザクションの実装で保証するのは「ファントムリードがないこと」であって、
>それを実現する方法は各RDBMSの実装にまかされている。

ファントムリードが起きない「だけ」なんだが、直列化可能性を保証するにはそれで十分なわけ。
まさか「ファントムリードがない」ってのを、単に他トランザクションで挿入したレコードを
見せないだけとでも思ってるんだろうか。

**デフォルトの名無しさん** · 2016/09/08(木) 10:04:35.37

>>511
もうお前の主張にはなにも興味はないが、mysqlとpostgresqlの実装にたいする感想くらいくれよ。

**デフォルトの名無しさん** · 2016/09/08(木) 10:09:10.39

>>511
> まあserializableで単独テーブルに対するアクセスでデッドロックするのもどうなんだという感じがしないでもないが
あ、これがmysqlの実装に対する感想なのか？
じゃ、もういいや。

**デフォルトの名無しさん** · 2016/09/08(木) 10:14:11.58

最後に一つだけ。
「SERIALIZABLEは無条件に直列化可能であることを保証するもの」の意味が全然わからんが、
ユニーク性を担保するためには、同時に実行される可能性があるトランザクションを「直列化」する
必要があり、それにはテーブルロックを使うのが最も簡単。

これに反論がある場合に限ってレスしてくれ。

**デフォルトの名無しさん** · 2016/09/08(木) 11:18:11.85

>>515への直接のレスがなければ、これでserializable話は終了します。
いい加減うざいだろうし。

「serializableなトランザクションとは何か」は、以下のスライドが俺が見つけた範囲だと一番わかりやすいと思う（それでもわかりづらいんだが）。
『トランザクションをSerializableにする4つの方法』
http://www.slideshare.net/kumagi/serializable4-56309007

**デフォルトの名無しさん** · 2016/09/08(木) 21:47:43.84

「SERIALIZABLEじゃ無理」→「問題がある」→「ロックの方が簡単」

なんだかなぁｗ
普通はトランザクション開始時に隔離レベルを1行指定する方がいちいちテーブルを指定して
ロックをかけるより簡単だと思うんだが。

「(今からトランザクションを理解するより)ロックの方が簡単」という個人的事情なのかね？

**デフォルトの名無しさん** · 2016/09/09(金) 03:27:30.69

>>517
ロックの詳細や問題点を正確に把握できてないんじゃないの

>serializableなトランザクションの場合、リトライすればOKな場合がある
>そういう面倒くさいことをしてまでも、ファントムリードを防がなければならないケースに限って、トランザクションを
> serializableにするというのが正しい使いだと思う。
と、あたかも自分でテーブルロックすれば他のトランザクションやリトライ系については考慮いらないかのようなこと言ってるし

>テーブルロックは常に成功するとでも思ってるんだろうか
っていう突っ込みに対して
>デッドロックになるようなロックのかけ方すればエラーになるだろうけど
って回答してるし
>デッドロックとロックタイムアウトの区別もつかない人か
についてはまともな反論してないからな

デッドロック以外にロックでエラーは出ないと思ってるんだろ

**デフォルトの名無しさん** · 2016/09/24(土) 11:55:19.93

再利用性の高いクエリの書き方を教えてください

**デフォルトの名無しさん** · 2016/12/04(日) 21:38:58.08

Oracleってdomain使えないん？

**デフォルトの名無しさん** · 2016/12/06(火) 22:37:42.39

今どきRDBMSとかダサすぎ。

**デフォルトの名無しさん** · 2016/12/15(木) 15:36:13.98

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja