Здравствуйте, Poul_Ko, Вы писали:
P_K>Неа. Пользовался TransactionScope, но он начал требовать DTC, хотя вся работа идёт с одной базой. P_K>Это известный баг,
Этот баг был в SQL Server 2005. У Вас же SQL Server 2008 R2, а в нём всё нормально. Если Вы наблюдали при этом эскалацию в распределённую транзакцию, то значит Вы определённо что-то делали неправильно. И, возможно, продолжаете делать.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Poul_Ko, Вы писали:
P_K>>Неа. Пользовался TransactionScope, но он начал требовать DTC, хотя вся работа идёт с одной базой. P_K>>Это известный баг,
D>Этот баг был в SQL Server 2005. У Вас же SQL Server 2008 R2, а в нём всё нормально. Если Вы наблюдали при этом эскалацию в распределённую транзакцию, то значит Вы определённо что-то делали неправильно. И, возможно, продолжаете делать.
Наверняка, вот только осталось найти где и что... Спасибо всем высказавшим предположения, буду ковырять код.
Здравствуйте, Poul_Ko, Вы писали:
P_K>Наверняка, вот только осталось найти где и что...
Так прямых вариантов эскалации немного: вложенные SqlConnection'ы; разные, с точки зрения пула, connection string'и, но указывающие на одну базу... А стектрейс у Вас есть...
Здравствуйте, drol, Вы писали:
D>Так прямых вариантов эскалации немного: вложенные SqlConnection'ы; разные, с точки зрения пула, connection string'и, но указывающие на одну базу... А стектрейс у Вас есть...
Дык стектрейс-то есть для исключений, возникших уже после того, как "снесло крышу". Исключения возникают на каждую выборку (.ToArray(), .FirstOrDefault(), ...), т.е. в совершенно разных местах. Перед первым таким исключением в логе ничего интересного не видно.
Из всего обсуждения я сделал такой вывод: из-за неаккуратной работы в многопоточной среде при определённом стечении обстоятельств что-то ломается и в результате время жизни контекстов EF рассинхронизируется с временем обработки запросов, откуда и возникают вложенные SqlConnection'ы и/или выборка из Dispose'нутых контекстов.
Здравствуйте, Poul_Ko, Вы писали:
P_K>Дык стектрейс-то есть для исключений, возникших уже после того, как "снесло крышу".
Это да. Однако, в месте исходной проблемы часто возникают внутренние исключения (например, InvalidOperationException), которые ловятся потрохами SqlClient и не пробрасываются наружу. Но они трэйсятся. Так что можно попробовать либо под отладчиком посмотреть, либо настроить трэйсинг для SqlClient и уже там.
Здравствуйте, drol, Вы писали:
D>настроить трэйсинг для SqlClient и уже там.
Хорошая идея, спасибо. Но как это сделать? SqlClient вроде не пользуется System.Diagnostics. Нашёл Data Access Tracing in SQL Server 2008, но выглядит это ужасно... Может знаете способ попроще?
