Пулът на връзките извиква sp_resetconnection преди рециклиране на връзка. Нулирането на нивото на изолация на транзакциите не е в списъка с неща, които sp_resetconnection прави. Това би обяснило защо "сериализуемите" течове в обединените връзки.
Предполагам, че бихте могли да започнете всяка заявка, като се уверите, че е на правилното ниво на изолация:
if not exists (
select *
from sys.dm_exec_sessions
where session_id = @@SPID
and transaction_isolation_level = 2
)
set transaction isolation level read committed
Друг вариант:връзките с различен низ за връзка не споделят пул за връзки. Така че, ако използвате друг низ за връзка за "сериализуемите" заявки, те няма да споделят пул със заявките "read committed". Лесен начин да промените низа за връзка е да използвате различно име за вход. Можете също да добавите произволна опция като Persist Security Info=False; .
И накрая, можете да се уверите, че всяка "сериализуема" заявка нулира нивото на изолация, преди да се върне. Ако "сериализуема" заявка не успее да завърши, можете да изчистите пула за връзки, за да извадите опетнената връзка от пула:
SqlConnection.ClearPool(yourSqlConnection);
Това е потенциално скъпо, но неуспешните заявки са рядкост, така че не трябва да извикате ClearPool() често.
