El grupo de conexiones llama a sp_resetconnection antes de reciclar una conexión. Restablecer el nivel de aislamiento de transacciones no está en la lista de cosas que hace sp_resetconnection. Eso explicaría por qué las fugas "serializables" en las conexiones agrupadas.
Supongo que podría comenzar cada consulta asegurándose de que esté en el nivel de aislamiento correcto:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Otra opción:las conexiones con una cadena de conexión diferente no comparten un grupo de conexiones. Entonces, si usa otra cadena de conexión para las consultas "serializables", no compartirán un grupo con las consultas de "lectura confirmada". Una manera fácil de modificar la cadena de conexión es usar un inicio de sesión diferente. También puede agregar una opción aleatoria como Persist Security Info=False; .
Finalmente, puede asegurarse de que cada consulta "serializable" restablezca el nivel de aislamiento antes de que regrese. Si una consulta "serializable" no se completa, puede borrar el grupo de conexiones para forzar la conexión corrupta fuera del grupo:
SqlConnection.ClearPool(yourSqlConnection);
Esto es potencialmente costoso, pero las consultas fallidas son raras, por lo que no debería tener que llamar a ClearPool() a menudo.
