web-dev-qa-db-ja.com

SET LOCK_TIMEOUT、それはセッションまたはステートメントベースですか？

LOCK_TIMEOUT最後？

SET LOCK_TIMEOUT 10とSELECT @@LOCK_TIMEOUTログイン後の1つのコマンドで、10が返されます。この直後私はSELECT @@LOCK_TIMEOUT再び、-1を返します。まだ10だと思っていたでしょう。

私はMSDNサイトを調べてみましたが、LOCK_TIMEOUTは、セッションベースまたはステートメントベースです。

sql-serversql-server-2008-r2lockingconfiguration
4
David Gray Wright

アプリケーションはsp_executesql経由でクエリを送信しますか？ （不明な場合はプロファイラーで確認できます）

EXEC sp_executesql N'SET LOCK_TIMEOUT 10; 
                     SELECT @@LOCK_TIMEOUT';

SELECT @@LOCK_TIMEOUT;

戻り値

-----------
10

-----------
-1

私のために。

編集exec sp_prepexecでも同じような動作が見られます

declare @p1 int

exec sp_prepexec @p1 output,
                 NULL,
                 N'SET LOCK_TIMEOUT 10; SELECT @@LOCK_TIMEOUT AS LOCK_TIMEOUT_INSIDE' 

select @p1 AS handle, @@LOCK_TIMEOUT AS LOCK_TIMEOUT_OUTSIDE
3
Martin Smith

から - SET LOCK_TIMEOUT Books Onlineエントリー：

「接続の開始時、この設定の値は-1です。変更後、新しい設定は残りの接続で有効です。」

私が実施したすべてのテストは、この文書化された動作を反映しています。おそらく異なる接続を使用していますが、同じセッションIDを取得していますか？このクエリを使用して、次のことを確認します。

SELECT 
    dec.connection_id, 
    dec.connect_time 
FROM sys.dm_exec_connections AS dec 
WHERE 
    dec.session_id = @@SPID;
4
Paul White 9

現在、SET LOCK_TIMEOUTのドキュメントには、接続の残りの部分で有効であると記載されていますが、これは完全に正しいわけではありません。他のSETステートメントと同じ規則に従います。

ストアドプロシージャまたはトリガーでSETステートメントが実行された場合、ストアドプロシージャまたはトリガーから制御が返された後、SETオプションの値が復元されます。また、SETステートメントがsp_executesqlまたはEXECUTEのいずれかを使用して実行される動的SQL文字列で指定されている場合、動的SQL文字列で指定されたバッチから制御が返された後で、SETオプションの値が復元されます。

https://docs.Microsoft.com/en-us/sql/t-sql/statements/set-statements-transact-sql

また、クエリの実行方法によっては、接続プールを使用している場合があります。これにより、同じ@@ spidが得られますが、exec sp_reset_connectionプールから接続を取得するとき。

1
Nicholas