Deadlocks may cause connection pool corruption when in a distributed transaction

Description

This issue is detailed in the following Stack Overflow question: http://stackoverflow.com/questions/8581956/deadlocks-causing-server-failed-to-resume-the-transaction-with-nhibernate-and

When a deadlock occurs on SQL Server, occasionally the exception will not be raised by the CLR. This has only happened in our environment when the SQL Server is under extreme (i.e. unnatural) load. It appears to be caused by the AdoNetWithDistributedTransactionsFactory closing the connection on transaction completion. There seems to be a race condition wherein the transaction rollback event may be raised before the deadlock error propagates across the connection. When this happens, the connection will be returned to the pool in an unusable state. Subsequent (brand-new) sessions will be unable to make a connection to the database. The error message varies depending on the situation. Usually it is one of the following:

The deadlock exception that should have been raised originally
The server failed to resume the transaction.
New request is not allowed to start because it should come with valid transaction descriptor.
The transaction has aborted.
Import of Microsoft Distributed Transaction Coordinator (MS DTC) transaction failed

As we've been able to reproduce similar behavior without using NHibernate, I believe at heart this is a bug in ADO.NET or maybe SQL Server. However I hope that NHibernate could be modified to avoid it. No patch because I don't have enough understanding of AdoNetWithDistributedTransactionsFactory.

This has been reproduced with the following variations: