O pool de conexões chama sp_resetconnection antes de reciclar uma conexão. Redefinir o nível de isolamento da transação não está na lista de coisas que sp_resetconnection faz. Isso explicaria por que vazamentos "serializáveis" em conexões agrupadas.
Acho que você pode iniciar cada consulta certificando-se de que esteja no nível de isolamento correto:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Outra opção:conexões com uma string de conexão diferente não compartilham um pool de conexões. Portanto, se você usar outra cadeia de conexão para as consultas "serializáveis", elas não compartilharão um pool com as consultas de "leitura confirmada". Uma maneira fácil de alterar a string de conexão é usar um login diferente. Você também pode adicionar uma opção aleatória como
Persist Security Info=False; . Por fim, você pode garantir que cada consulta "serializável" redefina o nível de isolamento antes de retornar. Se uma consulta "serializável" não for concluída, você poderá limpar o pool de conexões para forçar a conexão contaminada a sair do pool:
SqlConnection.ClearPool(yourSqlConnection);
Isso é potencialmente caro, mas as consultas com falha são raras, portanto, você não deve chamar
ClearPool() frequentemente. 
