SQL CLR – macht Lock-statement einen Unterschied?

Ich habe das folgende Stück Code geschrieben (sql clr gespeicherte Prozedur), die Nachrichten in eine lokale file schreibt. Das Problem tritt auf, wenn mehrere Verbindungen gleichzeitig den gespeicherten Proc aufrufen. Also habe ich eine Sperranweisung verwendet. Aber das scheint keinen Unterschied zu machen? Was mache ich hier falsch?

lock (SqlContext.Pipe) { StreamWriter sw = File.AppendText("C:\Date.txt"); int y = 50; while (y != 0) { sw.WriteLine(DateTime.Now + " " + serverName + " -- " + jobId.ToString() ); System.Threading.Thread.Sleep(new Random().Next()); y = y - 1; } sw.Close(); } 

Lock-statement allein schützt nichts. Die Magie passiert nur, wenn alle Threads das gleiche object verriegeln. In jedem Fall schließt jeder Thread seine eigene Kontextpfeife, das Verhalten wird identisch mit oder ohne Sperre sein.

Außerdem, von all dem Schaden ein CLR-Verfahren kann in SQL zu tun, entführt ein SQL-Arbeiter in Sleep warten () ist definitiv ein Top-Täter. Ich hoffe, Sie verwenden es nur für experimentelle Zwecke.

Um zu erreichen, was Sie wahrscheinlich wollen, dh. sp_getapplock nur eine Prozedur jederzeit ausgeführt, benutze eine Applikationssperre: sp_getapplock . Entweder wickeln Sie den CLR-Prozeduraufruf in T-SQL sp_getapplock / sp_releaseapplock oder führen Sie sp_getapplock auf der Kontextverbindung aus Ihrem CLR-Code aus (und führen Sie sp_releaseapplock auf Ihrem Ausweg aus).