Тупики, вызывающие "Не удалось возобновить транзакцию" с помощью NHibernate и распределенных транзакций

У нас возникает проблема при использовании NHibernate с распределенными транзакциями.

Рассмотрим следующий фрагмент:

//
// There is already an ambient distributed transaction
//
using(var scope = new TransactionScope()) {
    using(var session = _sessionFactory.OpenSession())
    using(session.BeginTransaction()) {
        using(var cmd = new SqlCommand(_simpleUpdateQuery, (SqlConnection)session.Connection)) {
            cmd.ExecuteNonQuery();
        }

        session.Save(new SomeEntity());
        session.Transaction.Commit();
    }
    scope.Complete();
}

Иногда, когда сервер находится под экстремальной нагрузкой, мы увидим следующее:

  • Запрос, выполняемый с cmd.ExecuteNonQuery, выбирается как жертва взаимоблокировки (мы можем видеть его в SQL Profiler), но исключение не возникает.
  • session.Save завершается с сообщением об ошибке: "Операция недействительна для состояния транзакции".
  • Каждый раз, когда этот код выполняется после этого, session.BeginTransaction терпит неудачу. Первые несколько раз меняется внутреннее исключение (иногда это исключение тупиковой ситуации, которое должно было быть поднято на шаге 1). В конце концов он стабилизируется так: "Сервер не смог возобновить транзакцию. Desc: 3800000177". или "Новый запрос не запускается, потому что он должен иметь действующий дескриптор транзакции".

Если оставить в покое, приложение в конечном итоге (через секунды или минуты) восстановится после этого условия.

Почему исключение тупиковой ситуации не сообщается на шаге 1? И если мы не сможем решить это, то как мы можем временно приостановить наше приложение?

Проблема была воспроизведена в следующих средах

  • Windows 7 x64 и Windows Server 2003 x86
  • SQL Server 2005 и 2008
  • .NET 4.0 и 3.5
  • NHibernate 3.2, 3.1 и 2.1.2

Я создал тестовое оборудование, которое иногда воспроизводит проблему для нас. Он доступен здесь: http://wikiupload.com/EWJIGAECG9SQDMZ

ОТВЕТЫ

Ответ 1

Мы, наконец, сузили это дело.

При открытии сеанса, если есть распределенная глобальная транзакция, NHibernate присоединяет обработчик события к Transaction.TransactionCompleted, который закрывает сеанс, когда распределенная транзакция завершена. Кажется, что это связано с условием гонки, в котором соединение может быть закрыто и возвращено в пул до того, как ошибка взаимоблокировки распространяется по всему, оставляя соединение в непригодном для использования состоянии.

Следующий код воспроизводит ошибку для нас время от времени, даже без нагрузки на сервер. Если на сервере имеется экстремальная нагрузка, он становится более последовательным.

using(var scope = new TransactionScope()) {
    //
    // Force promotion to distributed transaction
    //
    TransactionInterop.GetTransmitterPropagationToken(Transaction.Current);

    var connection = new SqlConnection(_connectionString);
    connection.Open();

    //
    // Close the connection once the distributed transaction is
    // completed.
    //
    Transaction.Current.TransactionCompleted += 
        (sender, e) => connection.Close();

    using(connection.BeginTransaction())
        //
        // Deadlocks but sometimes does not raise exception
        //
        ForceDeadlockOnConnection(connection);

    scope.Complete();
}

//
// Subsequent attempts to open a connection with the same
// connection string will fail
//

Мы не решили решение, но следующие проблемы устранят проблему (возможно, и другие последствия):

  • Отключение пула соединений
  • Использование NHibernate AdoNetTransactionFactory вместо AdoNetWithDistributedTransactionFactory
  • Добавление обработки ошибок, вызывающей SqlConnection.ClearPool() при возникновении ошибки "сервер не удалось возобновить транзакцию"

Согласно Microsoft (https://connect.microsoft.com/VisualStudio/feedback/details/722659/), класс SqlConnection не является потокобезопасным и включает закрытие соединения в отдельном потоке. Основываясь на этом ответе, мы отправили отчет об ошибке для NHibernate (http://nhibernate.jira.com/browse/NH-3023).

Ответ 2

не окончательный ответ, но я подозреваю, что у вас есть некоторые проблемы с управлением сеансом и что вы используете один и тот же сеанс для нескольких вызовов обработчикам. я не думаю, что это действительно соединение, которое находится в плохом состоянии, а скорее сеанс nhibernate. это не похоже на то, что вы не видите проблему с отключением пула соединений, поэтому я могу быть вне базы, но я все еще подозреваю, что это связано с повторным использованием сеансов.

Первое, что я хотел бы предложить, - это попытаться подтвердить это, зарегистрировав хэш-код сеанса и hashcode session.GetSessionImplementation() (мое понимание использования функции nhibernate для замка состоит в том, что вы увидите тот же экземпляр сеанс, хотя на самом деле это другой сеанс, и реализация сеанса фактически покажет разницу). см., если вы видите одни и те же хэш-коды, используемые при обработке разных сообщений.

Если это вопрос управления сеансом, попробуйте использовать модуль nservicebus для управления сеансами для ваших обработчиков. вот сообщение от andreas об этом. я не думаю, что его редактирование о том, как сделать это, встроенное в багажник, было в версии 2.5, поэтому вы, вероятно, захотите продолжить это. (я мог ошибаться в этом.)

http://andreasohlund.net/2010/02/03/nhibernate-session-management-in-nservicebus/

Ответ 3

Это не решит вашу проблему, но вы можете заставить свой IPreInsertEventListener просто отправить сообщение NSB, а затем передать получателю сообщения хранимую процедуру. Я делал это с проблемными прослушивателями до и после событий при использовании NHibernate и NSB в прошлом.

Еще одна мысль заключается в том, что ваш прослушиватель pre-event создаст свой собственный объект подключения, заключенный в приложение nice using, и не будет касаться соединения NHibernate. Если он блокируется, то просто сделайте бросок, убедитесь, что вы удалили какой-либо объект в области.

Ответ 4

Это проблема NHibernate. NHibernate не открывает и не закрывает соединение в том же потоке, который не поддерживается ADO.NET. Вы можете обойти это, открыв и закрыв соединение самостоятельно. NHibernate не будет закрывать соединение, если оно не открыло его.

Обход

var connection = ((SessionFactoryImpl)_sessionFactory).ConnectionProvider.GetConnection();
using(var session = _sessionFactory.OpenSession(connection))
{
   //do database stuff
}
connection.Close();