Forbindelsespuljen kalder sp_resetconnection før genbrug af en forbindelse. Nulstilling af transaktionsisolationsniveauet er ikke på listen over ting, som sp_resetconnection gør. Det ville forklare, hvorfor "serialiserbare" lækager på tværs af poolede forbindelser.
Jeg gætter på, at du kan starte hver forespørgsel ved at sikre, at den er på det rigtige isolationsniveau:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
En anden mulighed:forbindelser med en anden forbindelsesstreng deler ikke en forbindelsespulje. Så hvis du bruger en anden forbindelsesstreng til de "serialiserbare" forespørgsler, deler de ikke en pulje med "læs forpligtede" forespørgsler. En nem måde at ændre forbindelsesstrengen på er at bruge et andet login. Du kan også tilføje en tilfældig indstilling som Persist Security Info=False; .
Endelig kan du sikre dig, at hver "serialiserbar" forespørgsel nulstiller isolationsniveauet, før den vender tilbage. Hvis en "serialiserbar" forespørgsel ikke fuldføres, kan du rydde forbindelsespuljen for at tvinge den plettede forbindelse ud af poolen:
SqlConnection.ClearPool(yourSqlConnection);
Dette er potentielt dyrt, men fejlagtige forespørgsler er sjældne, så du skal ikke kalde ClearPool() ofte.