Pula połączeń wywołuje sp_resetconnection przed odtworzeniem połączenia. Resetowanie poziomu izolacji transakcji nie znajduje się na liście rzeczy, które robi sp_resetconnection. To wyjaśniałoby, dlaczego „możliwe do serializacji” wycieki w połączonych połączeniach.
Myślę, że możesz rozpocząć każde zapytanie od upewnienia się, że ma odpowiedni poziom izolacji:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Inna opcja:połączenia z innymi parametrami połączenia nie współdzielą puli połączeń. Jeśli więc używasz innych parametrów połączenia dla zapytań "możliwych do serializacji", nie będą one udostępniać puli z zapytaniami "odczyt zatwierdzonymi". Prostym sposobem na zmianę parametrów połączenia jest użycie innego loginu. Możesz także dodać losową opcję, taką jak Persist Security Info=False; .
Na koniec możesz upewnić się, że każde zapytanie „możliwe do serializacji” resetuje poziom izolacji przed zwróceniem. Jeśli "serializowalne" zapytanie nie zostanie zakończone, możesz wyczyścić pulę połączeń, aby wymusić skażone połączenie z puli:
SqlConnection.ClearPool(yourSqlConnection);
Jest to potencjalnie kosztowne, ale nieudane zapytania są rzadkie, więc nie powinieneś wywoływać ClearPool() często.
