No, because as far as I am concerned, this _is_ valid code. I still need to
track down exactly what is going on, though.

On Sun, Mar 22, 2009 at 2:51 PM, Fabio Maulo <[email protected]> wrote:

> Have you tried using session.BeginTransaction ?
>
> 2009/3/22 Ayende Rahien <[email protected]>
>
> Oh, it most certainly is.It execute that on the prepare phase.
>> That is expected. The problem is _why_ it is doing this.
>> Because the connection is open in the start phase.
>>
>>
>> On Sun, Mar 22, 2009 at 2:09 PM, Matthijs ter Woord <
>> [email protected]> wrote:
>>
>>>
>>> This exception happens whenever you try to use a transaction
>>> (distributed transaction in this case) which has already been
>>> completed. I think NHibernate is too late in executing the Delete
>>> statement.
>>>
>>> On Sun, Mar 22, 2009 at 6:57 PM, Ayende Rahien <[email protected]>
>>> wrote:
>>> > 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.
>>> >
>>> >
>>>
>>
>>
>
>
> --
> Fabio Maulo
>

Reply via email to