ホームページ > データベース > mysql チュートリアル > 注文処理キューにおける SQL Server の競合状態を解決するにはどうすればよいですか?

注文処理キューにおける SQL Server の競合状態を解決するにはどうすればよいですか?

Susan Sarandon
リリース: 2025-01-18 01:26:12
オリジナル
709 人が閲覧しました

How to Resolve a SQL Server Race Condition in an Order Processing Queue?

注文処理における SQL Server の競合状態への対処

この記事では、ストアド プロシージャを介して注文キューにアクセスするときに、複数の注文プロセッサが競合状態に遭遇するという一般的な問題に取り組みます。 このストアド プロシージャは、一意の ID を使用して、次の 20 個の注文を処理用にロックします。 ただし、同時アクセスにより複数のプロセッサが同じ順序を要求し、処理エラーが発生する可能性があります。

根本的な原因は、コミットされていないトランザクションの可視性です。 通常は同時行アクセスを防止する ROWLOCK を使用しても、コミットされていない変更はロックをチェックしている他のプロセッサには表示されません。これにより競合状態が発生します。

解決策には、READPAST ステートメントと UPDLOCK ステートメントで SELECT ヒントと UPDATE ヒントを使用することが含まれます。 READPAST は、コミットされていない更新による干渉を回避するために、ロックされた行をバイパスするようにデータベースに指示します。 UPDLOCK は、トランザクションがコミットされるまで更新された行を排他的にロックし、他のプロセッサが行を変更できないようにします。

これらのヒントを組み込んだ改良されたコードは次のとおりです。

<code class="language-sql">BEGIN TRAN
    UPDATE TOP (20) foo
    SET ProcessorID = @PROCID
    FROM OrderTable foo WITH (ROWLOCK, READPAST, UPDLOCK)
    WHERE ProcessorID = 0
COMMIT TRAN

SELECT OrderID, ProcessorID, etc...
FROM OrderTable
WHERE ProcessorID = @PROCID</code>
ログイン後にコピー

効率を高めるには、OUTPUT 句の使用を検討してください。これにより、SELECT 操作と UPDATE 操作がマージされ、テーブルが更新され、変更された行が 1 つのステップで返されます。これにより、別の SELECT ステートメントが不要になります。

以上が注文処理キューにおける SQL Server の競合状態を解決するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
著者別の最新記事
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート