Der Verbindungspool ruft sp_resetconnection auf, bevor eine Verbindung wiederverwendet wird. Das Zurücksetzen der Transaktionsisolationsstufe ist nicht in der Liste der Dinge, die sp_resetconnection tut. Das würde erklären, warum „serialisierbare“ Lecks über gepoolte Verbindungen hinweg auftreten.
Ich denke, Sie könnten jede Abfrage starten, indem Sie sicherstellen, dass sie sich auf der richtigen Isolationsstufe befindet:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Eine weitere Option:Verbindungen mit einer anderen Verbindungszeichenfolge teilen sich keinen Verbindungspool. Wenn Sie also eine andere Verbindungszeichenfolge für die „serialisierbaren“ Abfragen verwenden, teilen sie sich keinen Pool mit den „Read Committed“-Abfragen. Eine einfache Möglichkeit, die Verbindungszeichenfolge zu ändern, besteht darin, eine andere Anmeldung zu verwenden. Sie könnten auch eine zufällige Option wie Persist Security Info=False; hinzufügen .
Schließlich könnten Sie sicherstellen, dass jede "serialisierbare" Abfrage die Isolationsstufe zurücksetzt, bevor sie zurückkehrt. Wenn eine „serialisierbare“ Abfrage nicht abgeschlossen werden kann, können Sie den Verbindungspool löschen, um die fehlerhafte Verbindung aus dem Pool zu zwingen:
SqlConnection.ClearPool(yourSqlConnection);
Dies ist möglicherweise teuer, aber fehlschlagende Abfragen sind selten, daher sollten Sie ClearPool() nicht aufrufen müssen oft.
