Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,844

filter by tags archive

NH-1711 – Inappropriate error handling with NH 2.1 Alpha 1 when distributed transaction fails can cause application crashes

time to read 2 min | 378 words

The actual problem has been fixed and it will be part of NH 2.1 Alpha 2. That is why we call them alphas, after all :-)

The actual bug is pretty convulsed mess, to be frank. And it is no wonder that it slipped by me. Yes, I am the one responsible for that, so I guess I am making excuses. Let me tell you about the actual scenario. When you are using NHibernate 2.1 Alpha 1 (it does not affect NHibernate 2.0 or 2.0.1) with a System.Transaction.Transaction, there is a slightly different code path that we have to go through, because the actual work that has to be done is no longer controlled by NHibernate, but by the DTC infrastructure.

So far, so good. The problem is that most of the time, this is done on the same thread as the application that we are running on. There are cases, specifically, when using a DTC with multiple durable enlistments, that the actual work is done on a worker thread. The problem is that if there is an error during that phase, for example, if we are trying to execute invalid command, or run into transaction deadlock, NHibernate wouldn’t properly handle this error, and it would bubble up. The result of unhandled thread exception is, of course, an application crash.

That is considered to be a bad thing, I understand, so after being able to isolate the problem, I went ahead and fix this. You can get the trunk now and get the fix, or wait until Alpha 2 is released.

Who is impacted by this?

You have to use multiple different durable enlistments inside a distributed transaction for the error condition to even be applicable. The problem is that there is one very common scenario that will run into this every single time. The .NET Service Buses all wrap their processing in a TransactionScope, and then tend to have multiple durable enlistments (the DB and MSMQ). This means that if you are using NServiceBus, Rhino ServiceBus or MassTransit alongside with NHibernate 2.1 Alpha1, you are probably impacted by this issue.

As I mentioned, a fix has already been committed (r4149) and it will be part of NHibernate 2.1 Alpah2.


Steve Degosserie

Hey Ayende,

Isn't that related to NH-1676 and maybe also NH-1711 ?

Ayende Rahien

No, those are different, but I'll look into those as well.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats