4

対処しようとしている問題があります。テーブルの読み取りを一時的にロックする必要があります。

これがシナリオです。

ベース番号で始まる使用される最大販売注文を決定するために、テーブルを読み取る必要があります。次に、小数点の後に数字を追加する必要があります。したがって、注文が 123.1 と 123.2 の場合、次に作成する必要があるのは 123.3 であると判断する必要があります。次に、API を呼び出してこの注文番号を作成します。

問題は、2 人のユーザーが同時に新しい販売注文をベース 123 の注文番号に追加したい場合です。あるユーザーのロジックは、番号が 123.3 であると判断し、API を呼び出して注文を作成します。作成したら、レコードをコミットします。ただし、API 呼び出しが開始されている間、2 番目のユーザーのロジックは次の番号を決定しようとしており、タイミングによっては、次に利用可能な番号として 123.3 を選択することもできます。

次に、2 番目のユーザーのロジックが API を呼び出すと、番号が重複してエラーになります。

注文番号を決定して作成している間、最初のロジックでテーブルを読み取りからロックしたいと考えています。次に、ロックを解除すると、2 番目のユーザーが続行できます。

私が読んだことはすべて、テーブルの読み取りをブロックできないと言っているようです。

4

2 に答える 2

5

ORDERとの 2 つのテーブルを使用できますORDER_LINE

数値を生成する手順は、 を実行しSELECT * FROM order WHERE order_id = 123 FOR UPDATE、 の行から適切な数値を決定しますORDER_LINE

2 つのセッションが同じ API を同時に呼び出した場合order_id、そのうちの 1 つは最初のセッションがコミット/ロールバックするまで待機します。最初のセッションがコミットされると、2 番目のセッションがマスター テーブルをロックし、次に次の番号を取得します。

order_idセッションは、待機なしで同時に呼び出すことができます。

同時更新の場合に待機したくない場合は、 を使用FOR UPDATE NOWAITして、注文が別のユーザーによってロックされているというメッセージを返します。

于 2013-05-29T15:34:35.743 に答える