基本的なトリガーロックの問題

Question

トリガーに関する質問が1つあります。表XYZの AFTER - シナリオは、今私がINSERTにトリガーを配置している。この

Create Procedure 
begin 
    Insert into XYZ (a) values (b) 
end 

のようなものです。そのトリガーで それを実行するために2〜3秒かかり、ビジネスロジックが

ので、私は一度INSERTが行われていることをここに確認するために必要なものをXYZテーブルの上にビジネスロジックは、他のデータベーステーブルに対して実行され、そこではありませんテーブルXYZは別のレコードの挿入を行う準備ができているか、トリガが完了するまでロックされますか？私はこの問題に関するいくつかのより多くの研究を行い、INSERTで の下にそれを説明している

EDIT

- TRIGGER、私は今、私のビジネスロジックを入れても、線の下の

WAITFOR DELAY '00:01' 

ています私が上記のSPを実行しようとすると、SPは1分（トリガーで1分の遅延を指定したため）完了せず、テーブルXYZもこの期間中ロックされました。

このように、トリガーで同じテーブルを使用していなくても、トリガーはテーブルをロックします。私は正しい？誰もがここで別の意見を持っていますか？

Answer 1

質問と@Hallainzilによってリンク答えが一つのアプローチを示しています。ストアドプロシージャに

• ラップ、すべてのテーブルの挿入と更新
• 、ロック
を維持することなく、追加のビジネスロジックを完了することができますSP

また、いくつかのやり方で少し厄介ですが、多くの点でより柔軟です。

• 210は、フィールドの挿入や
は、それらの変更

あなたはそのレコードを維持するためにトリガーを使用することを処理するために繰り返しまたは一晩エージェントジョブの火を持って更新されているの記録を保管してください。たぶん、LastModifiedTimeフィールド、またはhasBeenProcessedフィールド、あるいは別のトラッキングテーブルでさえ。それは多くの方法で行うことができ、維持するために比較的軽量です（ビジネスロジックはまったく起こりません）。

これは、できるだけ早くロックからテーブルを解放します。また、ストアドプロシージャを迂回してテーブルに直接書き込むことができるログインを処理できることも意味します。

欠点は、INSERT/UPDATESとビジネスロジックが非同期で処理されていることです。他のSQLコードでは、INSERTとビジネスロジックの両方が常にアトミックに行われると仮定するのではなく、ビジネスロジックがまだ完了しているかどうかをチェックする必要があります。

はい、このロックを回避する方法があります。しかし、モデルに追加の制約や複雑さが導入されます。これは決して悪いことではありませんが、全体的な設計の中で考慮する必要があります。