well... probably, and I repeat probably, in your case the injection (trough
NH-configuration) of your own TransactionFactory would be appropriate and
there you can continue calling BeginTransaction.
What we should remember here is that a NH-Transaction is a NH-Transaction
and not a ADO.NET transaction. Using a custom TransactionFactory you can
share the same ADO.NET transaction between the DAB and NH and when you will
have removed DAB you don't need to touch your code, you only need to use the
default TransactionFactory (trough NH-configuration).

2009/3/23 Michael Teper <[email protected]>

>  Fabio, the situation that I am working with is probably not that common,
> but I will describe it, and maybe you can offer some advice.
>
> There is a very large legacy application that predated NH and has gone
> through several design iterations, such that it has several data access
> abstractions on top of ADO.NET. (calling SqlClient.* direcly, through
> ApplicationBlock.Data, etc.) NHibernate is being introduced gradually, and
> until the conversion is complete, we have this mixed environment where some
> stuff is NH-enabled and some is not.
>
> One of the areas where this is cumbersome is transaction management. A fair
> bit of object interaction is abstracted into higher-order components. The
> choice of which transaction mechanism is appropriate is not always obvious,
> thus making TransactionScope really attractive. If we could just use that,
> and rely on everything down the line to play nicely with it, it would
> dramatically simplify working with this environment. In other words, it
> would be very attractive for me to *not* have to call
> session.BeginTransaction explicitly.
>
> Does that make sense?
>
> Thanks!
> -Michael
>
>
>  ------------------------------
> *From:* [email protected] [
> [email protected]] On Behalf Of Fabio Maulo [
> [email protected]]
> *Sent:* Monday, March 23, 2009 10:38 AM
>
> *To:* [email protected]
> *Subject:* [nhibernate-development] Re: More DTC issues
>
>  When you are calling session.BeginTransaction you don't know if it happen
> inside a DTC or no, right ? You don't know if/when/who start a DTC.
>
>  From Oren example
> 1/ low level infrastructure - dtc
> 2/ high level infarstruture - nh
> 3/ business code - your stuff
> 3/ your stuff end
> 2/ session.Flush, nh-transaction commit, session.Dispose
> 1/ Complete
>  but you don't know if NH-code is running inside a DTC, as "your-stuff",
> or part of it, don't know that it is running inside DTC+NH.
>
>  What you do in the "high level infarstruture" is
> openSession+session.BeginTransaction without take care if a "low level
> infrastructure" component start a DTC.
>
>  Or you want put something like
> if(DTC) {aBehaviorOfNhSession+Transaction} else 
> {anotherBehaviorOfNhSession+Transaction}
> ? hopefully no.
>
>  The user don't need to know to call session.BeginTransaction because call
> it is a simple best/required-practice. The user should call
> session.BeginTransaction always without take care about DTC.
>
>
> 2009/3/23 Michael Teper <[email protected]>
>
>>  But *does* the user need to know to call session.BeginTransaction? In my
>> example, are you saying that I would need to explicitly manage bot
>> the TransactionScope and NH ITransaction ?
>>
>> Thanks!!
>> -Michael
>>
>>
>>  ------------------------------
>>  *From:* [email protected] [
>> [email protected]] On Behalf Of Fabio Maulo [
>> [email protected]]
>>  *Sent:* Monday, March 23, 2009 10:13 AM
>>
>> *To:* [email protected]
>> *Subject:* [nhibernate-development] Re: More DTC issues
>>
>>    For those reasons the ITransaction shouldn't be a merely 
>> "ADO.NETtransaction wrapper" (or so near to it). session.BeginTransaction
>> should know which is the environment, it should know if it should run in a
>> nested DTC transaction ... and so on.
>> The user only need to know that i must call session.BeginTransaction, NH
>> should to the right thing.
>>
>> 2009/3/23 Michael Teper <[email protected]>
>>
>>>  Fabio, Ayende,
>>>
>>> Another thing to consider is the nested transaction scenario like this:
>>>
>>> using (var scopeOuter = new TransactionScope())
>>> {
>>>    // load / change some object(s)
>>>
>>>    using (var innerScope = new TransactionScope())
>>>    {
>>>        try
>>>        {
>>>            // load / change something else
>>>            innerScope.complete();
>>>        }
>>>        catch { // do something }
>>>     }
>>>
>>>     outerScope.complete();
>>> }
>>>
>>> This may look silly but if the inner transaction is encapsulated in a
>>> different class, this is a very plausible scenario. Wherever NH keeps track
>>> of the current transaction scope, it needs to be aware of potential for
>>> nesting.
>>>
>>> Thanks!
>>> -Michael
>>>
>>>
>>>  ------------------------------
>>> *From:* [email protected] [
>>> [email protected]] On Behalf Of Fabio Maulo [
>>> [email protected]]
>>> *Sent:* Monday, March 23, 2009 9:45 AM
>>> *To:* [email protected]
>>> *Subject:* [nhibernate-development] Re: More DTC issues
>>>
>>>
>>>
>>> 2009/3/23 Ayende Rahien <[email protected]>
>>>
>>>> The problem is that usually the DTC is opened by a lower level
>>>> component, and my code has no control over it. More than that, I
>>>> usually don't have control over NH's code as well.
>>>>
>>>>  It goes like this:
>>>>
>>>>  1/ low level infrastructure - dtc
>>>> 2/ high level infarstruture - nh
>>>> 3/ business code - my stuff
>>>>
>>>
>>>  and then
>>> 3 -end
>>> 2- end
>>> 1-end
>>>
>>>  If 2 don't know about 1, 2 should use session.BeginTransaction and
>>> session.Transaction.Commit().
>>>
>>>
>>>>
>>>>  I don't want to be aware of all of this issues, I just want to make
>>>> this work.
>>>> So explicitly flushing is an option that I would generally be against.
>>>>
>>>>  Making NH's transaction equal to the dtc is also not a good option,
>>>> because the use of the DTC is to manage several resources, not just NH.
>>>>
>>>
>>>  You know... I never said dtc=nhTx
>>> What I would like to avoid is If(DTC) {something} else {somethingelse}
>>> inside NH-Core.
>>>
>>>  --
>>> Fabio Maulo
>>>
>>
>>
>>
>> --
>> Fabio Maulo
>>
>
>
>
> --
> Fabio Maulo
>



-- 
Fabio Maulo

Reply via email to