2

これはばかげた質問かもしれませんが、これらのストアド プロシージャの作成方法が問題を引き起こす可能性があるかどうかはよくわかりません。

私のselectストアドプロシージャは次のようになります：

ALTER PROCEDURE [dbo].[GetSRPsToProcess]
    @CurrentTime DateTime
AS
BEGIN
    BEGIN TRAN Tran1
        Select TOP 20 *
        From SRPQueue WITH (updlock, ROWLOCK, readpast)
        WHERE SRPQueue.TimeToDequeue <= @CurrentTime AND SRPQueue.Status = 'Pending'
        ORDER BY SRPQueue_Index 
    COMMIT
END

私の削除手順は次のようになります (最終的にはログ テーブルへの挿入も含まれます)。

ALTER PROCEDURE [dbo].[DequeueRelevantSRPs]
    -- Add the parameters for the stored procedure here
    @SRPQueue_Index int,
    -- @TimeDeleted datetime
AS
BEGIN
    BEGIN TRAN Tran1
        Delete
        FROM SRPQueue
        WHERE SRPQueue.SRPQueue_Index = @SRPQueue_Index
    COMMIT
END

DequeueRelevantSRPs ストアド プロシージャが既に選択され、ロックされている行を削除しようとする (そして失敗する) という問題を回避するためのベスト プラクティスは、SRPQueue.Status 変数を使用することでしょうか?

いくつかの異なるステータス (保留中、処理中、準備完了、失敗) を持つことができ、追加の AND SRPQueue.Status = 'Ready' チェックが必要なだけなので、これは素晴らしいことです。潜在的なロックにもかかわらず、削除が成功することを確認できる別の方法はありますか?

編集: これらのストアド プロシージャを呼び出すアプリケーションは、複数のサーバー上の複数のインスタンスで実行されます。ちょっと重要な詳細>.>.

4

1 に答える 1

0

挿入、更新、および削除の命令は、トランザクション内のテーブルをロックし、テーブルのロックが解除されるのを待つ選択...

TRANなしで1st SPを作ります

ALTER PROCEDURE [dbo].[GetSRPsToProcess]
    @CurrentTime DateTime
AS
BEGIN

        Select TOP 20 *
        From SRPQueue WITH (updlock, ROWLOCK, readpast)
        WHERE SRPQueue.TimeToDequeue <= @CurrentTime AND SRPQueue.Status = 'Pending'
        ORDER BY SRPQueue_Index 

END
于 2013-02-19T23:21:49.027 に答える