Hm, another problem that I run into, and I am not sure what the problem is:
public void CanDeleteItemInDtc()
{
object id;
using (var tx = new TransactionScope())
using (var s = sessions.OpenSession())
{
id = s.Save(new Person
{
CreatedAt = DateTime.Today
});
new ForceEscalationToDistributedTx();
tx.Complete();
}
using (var tx = new TransactionScope())
using (var s = sessions.OpenSession())
{
new ForceEscalationToDistributedTx();
s.Delete(s.Get<Person>(id));
tx.Complete();
}
}
This is failing with a System.Data.SqlClient.SqlException: Distributed
transaction completed. Either enlist this session in a new transaction or
the NULL transaction.
On Sun, Mar 22, 2009 at 9:55 AM, Ayende Rahien <[email protected]> wrote:
> Correction, the DTC infrastructure will report the transaction failure back
> on TX dispose.Sweat, so my solution looks good enough to push for
> production.
>
>
> On Sun, Mar 22, 2009 at 9:52 AM, Ayende Rahien <[email protected]> wrote:
>
>> Just run into this issue.
>>
>> What would you expect this to do?
>>
>>
>>
>> [Test]
>>
>> public void WillNotCrashOnDtcPrepareFailure()
>>
>> {
>>
>> using(var tx = new TransactionScope())
>>
>> {
>>
>> using (var s = sessions.OpenSession())
>>
>> {
>>
>> s.Save(new Person
>>
>> {
>>
>> CreatedAt = DateTime.MinValue // will cause SQL date
>> failure
>>
>> });
>>
>> }
>>
>>
>> new ForceEscalationToDistributedTx();
>>
>>
>> tx.Complete();
>>
>> }
>>
>> }
>>
>>
>> The problem is that when we fully escalate to distributed tx, the actual
>> commit is going to happen on a different thread.
>> If an exception is thrown by the commit, this is going to crash the entire
>> process.
>> Now, my problem is that I am not sure what NH's behavior should be in this
>> regard, because we don't have a good way of reporting the error to the user
>> at this point.
>> I am going to commit a fix that will swallow the exception, force a
>> rollback on the DTC and log an error.
>> I am not _happy_ about that, but I can't think of anything that will be
>> better.
>>
>
>
