1


0

CONTEXT_INFO select context_info()を設定し、ロックします

次のように使用されるテーブルTを想像してください。

時刻T0:SPID 1:トランザクションの開始…​ T(…​)に挿入しますvalues(…​); …​ コミット;

時刻T1 SPID 2:でトランザクション選択を開始* TからC = cval; …​ コミット;

トランザクション分離レベルがシリアライズ可能に設定されていると想定します。 また、SPID1が時刻T1よりも前にTでTABLOCKXを取得し、SPID1が長いトランザクションを実行して、最終的にSPID2がTのTABLOCKXの解放を待機していると仮定します。

ここで、Tの代わりにCONTEXT_INFOを使用して同じシナリオを検討します

時刻T0:SPID 1:トランザクションの開始…​ SET CONTEXT_INFO = 0xFF; …​ end;

時間T1 SPID 2で、トランザクション選択context_info()を開始します。 …​ end;

繰り返しますが、トランザクション分離レベルがシリアライズ可能に設定されていると仮定します。

CONTEXT_INFOは接続ごとです。 SPID 1とSPID 2がCONTEXT_INFOを使用して通信しているとは思わない。 それらは完全に独立しており、同時にCONTEXT_INFOを別々の目的で使用していると仮定します。

現在、選択はTABLOCKXによる待機なしで実行されます。 実際のところ、CONTEXT_INFOを使用してロックするため、どのタイプの待機も引き起こすことができませんでした。

私はこの振る舞いが必要なので、これは私には問題ありません。 私の問題は、CONTEXT_INFOが "SPID-represenation"のSQLサーバーのメモリ変数であるべきであるにもかかわらず、MSSQL2000のmaster.dbo.sysprocessesというテーブルに格納されているように見えることです(select context_info()はここでは機能しません) MSSQL Serverの以降のリリースのsys.sysprocessesで。

これらのテーブルは、ロックに関して他のすべてのテーブルと同じように動作しませんか?または、これらのテーブルは、他のテーブルと同じルールに従わない変数への単なる窓ですか?

もう1つ印象に残っているのは、spt_valuesのTABタイプのISモードロックは、sysprocessesの読み取り時にcontext_infoおよびKEYタイプのRangeS-Sモードロックを設定することです。 しかし、これの本当の結果は内部オブジェクトであるため、私は把握していません。

私を啓発してください。

よろしく、イェンスノルデンブロ

'' '' '

  • CONTEXT_INFOが接続ごとであることはわかっています。 I do SPID 1とSPID 2がCONTEXT_INFOを使用して通信しているとは限りません。 それらは完全に独立しており、CONTEXT_INFOを個別の目的に使用していると仮定しています。 私は彼らが同じロックリソースを必要とすることを恐れています。 それが本当の問題です。

  • ヒントとはどういう意味ですか?

1 Answer


1


  • CONTEXT_INFOは接続ごとです

  • sysprocessesは実際のテーブルではないため、HINTを使用できません(例:WITH TABLOCKX)

編集、OPによる他の回答の後:

sysprocessesには、コードに影響するロックや競合はありません。 つまり、CONTEXT_INFOの使用は、sysprocessesで内部的に行われるものの影響を受けません。

「本物のテーブル」は…​ これは、http://technet.microsoft.com/en-us/library/ms176105.aspx [OBJECTPROPERTY]の「TableIsFake」テストによる「偽のテーブル」です。

_ テーブルは本物ではありません。 SQL Serverデータベースエンジンにより、オンデマンドで内部的に具体化されます。 _