Le pool de connexions appelle sp_resetconnection avant de recycler une connexion. La réinitialisation du niveau d'isolation des transactions ne figure pas dans la liste des opérations effectuées par sp_resetconnection. Cela expliquerait pourquoi les fuites "sérialisables" sur les connexions groupées.
Je suppose que vous pourriez commencer chaque requête en vous assurant qu'elle est au bon niveau d'isolement :
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Autre option :les connexions avec une chaîne de connexion différente ne partagent pas un pool de connexions. Ainsi, si vous utilisez une autre chaîne de connexion pour les requêtes "sérialisables", elles ne partageront pas de pool avec les requêtes "lecture validée". Un moyen simple de modifier la chaîne de connexion consiste à utiliser un identifiant différent. Vous pouvez également ajouter une option aléatoire telle que Persist Security Info=False; .
Enfin, vous pouvez vous assurer que chaque requête "sérialisable" réinitialise le niveau d'isolement avant son retour. Si une requête « sérialisable » ne se termine pas, vous pouvez effacer le pool de connexions pour forcer la connexion contaminée à sortir du pool :
SqlConnection.ClearPool(yourSqlConnection);
C'est potentiellement coûteux, mais les requêtes qui échouent sont rares, vous ne devriez donc pas avoir à appeler ClearPool() souvent.
