[前][次][番号順一覧][スレッド一覧]

mysql:8483

From: "江口" <"江口" <eguchi@xxxxxxxxxx>>
Date: Thu, 11 Dec 2003 15:28:14 +0900
Subject: [mysql 08483] Re: innoDB の行排他ロックについて

ひろせ様

いつもお世話になります。江口です。ご意見ありがとうございます。
回答が遅くなり申し訳ありません。

>レコード数が多かろうが少なかろうが、
>
>> > MySQLで大量データを持つ表に対しある処理で一部レコードを更新
>                                             ^^^^^^^^^^^^
>> > しながら別の処理で他のレコードを更新することが実現可能か
>                      ^^^^^^^^^^^^
>
>処理 1 と処理 2 の更新対象レコードが独立ならば、更新処理同士の競合回避
>という点で SELECT 〜 FOR UPDATE は必要ないし、恐らくトランザクション処
>理も必要ないのではないかと思うのですが、実際の処理内容はもっと複雑なの
>でしょうか?
>
>それと
>
>> > どうかの調査を行っており、Oracleでの開発を行った経験から
>> > 双方の処理で行の排他ロックを掛ける必要があると思っています。
>
>Oracle でどいう問題があったのかも気になります。


処理内容は特に複雑なわけではありません。
トランザクション処理を使用する目的はなんらかの障害が発生した
ときにトランザクションの開始時点までrallbackさせたい。
と考えています。

行排他ロックを使用する目的はデータの保護を意識的に行えば、
エラー発生後のデータを確実に復旧しやすいのではないか
と考えるためです。
なぜ表ロックしてしまわないのかというと
(例えば今回のように行排他ロックを行ったつもりが
 表ロックされてしまうことがなぜ好ましくないのかといえば)
想定しているシステムではそれぞれの処理が完了するまで
別の処理で更新ができないとなると運用に耐えないシステム
となってしまうと考えたからです。
*これが大量データ云々の部分に関係します。
 説明が不足しており申し訳ありませんでした。

Oracleに限った話ではないと思いますが
別の製造者が作成した、表ロック、行排他ロック、暗黙のロック(というんでしょう
か?)
を使用したプログラムが同時に動作した場合、デッドロックが発生する
確率が高くなるのではないかと思っています。


[前][次][番号順一覧][スレッド一覧]

      8466 2003-12-10 14:40 ["江口" <eguchi@xxxxx] innoDB の行排他ロックについて           
      8467 2003-12-10 18:28 ┗[とみたまさひろ <tomm]                                       
      8468 2003-12-10 18:58  ┣["江口" <eguchi@xxxxx]                                     
      8471 2003-12-10 19:10  ┃┗["江口" <eguchi@xxxxx]                                   
      8469 2003-12-10 19:08  ┗["HIROSE, Masaaki" <h]                                     
      8472 2003-12-10 19:22   ┣["HIROSE, Masaaki" <h]                                   
->    8483 2003-12-11 15:28   ┗["江口" <eguchi@xxxxx]