> OK, is my last post on this thread. I won't waste more time, so feel free
> to continue your bashing.
> In Microsoft, all features start at minus 100 points, because they take
> effort to implement, document, and test for compatibility.
> So far, you have failed to prove that your feature goes beyond a minor
> convenience issue, and to resolve the potential inconsistencies, much less
> provide any actual pointers on how such a feature might be implemented.
> I don't know what you are "trying to start here", but I given examples and
> reasons why it would be hard (or impossible) to implement that in NH.
> Regarding the model: You can have N-transactions and transaction scopes
> per session; you just have to create the transactions inside the
> scopes (remember transactionscopes are primarily wrappers for distributed
> transactions). If your code uses different assumptions, that's fine, but
> don't blame NH for that.
> You are free to use any ORM you like (I do use EF in some projects, having
> choices is wonderful).

>     Diego

> On Mon, Apr 16, 2012 at 14:22, John T wrote:

>> And yet TransactionScope is still designed to be the one place that
>> developers like you and I need to Complete a transaction.

>> Else what is the point of using it? To create a n phase commit just for
>> fun? What is the purpose of
>> System.Transactions.Transaction.TransactionCompleted if not to do exactly
>> this?

>> As for your last somewhat irrelevant point: So what if there are only
>> "five" people asking? So what if they aren't given patches, nor looked at
>> the implementation in detail? What the hell do you think I'm trying to
>> start here? I'm not demanding this be fixed for me, I'm starting a
>> discussion on how can NH achieve this. In my very first post I have asked
>> if anyone has hit any barriers in any previous attempts to do this before.
>> So far, I've gathered that there is a very big barrier in the shape of a
>> huge "holier than thou" attitude from certain devs that sit on their
>> haunches and bleat the same tired arguments "you aren't going to need it"
>> and "you're doing it wrong."

>> The very idea behind TransactionScope is so that I, nor anyone else, do
>> not need to make any more than ONE explicit commit/rollback call in my
>> code. And here on this list I am being told (incorrectly) that that is not
>> the case. I'm being told that I must create a session after a
>> transactionscope. Whilst that was/is helpful advice (it does "work") it, as
>> is explained by one of the comments in NH-2107 quite elegantly with
>> diagrams, breaks the model of session vs transaction. Many
>> transaction(scope)s per session. Not one-to-one
>> session-to-transaction(scope). Or worse, many sessions to one
>> transaction(scope).

>> Regards,
>> J.

>> On Monday, April 16, 2012 6:04:58 PM UTC+1, Diego Mijelshon wrote:

>>> There are a few problems:
>>> - What you posted is absolutely different from the NH-2107. There, the
>>> session is being opened inside the transactionscope, which is a point where
>>> an ambient transaction COULD be detected.
>>> - I won't even try to compare this to the (discontinued) L2S, which
>>> doesn't use POCOs.
>>> - What is "the number of people asking for exactly the same thing"?
>>> There are thousands of projects using NH, none of which has problems with
>>> using NH transactions alone, or combined with TransactionScope. Five users,
>>> none of which seem to have looked at the implementation and implications of
>>> what they suggest, or provided a patch, are far from being a significative
>>> sample.

>>>     Diego

>>> On Mon, Apr 16, 2012 at 13:12, John T wrote:

>>>> typo in previous: https://nhibernate.jira.com/browse/NH-2107

>>>> On Monday, April 16, 2012 5:02:27 PM UTC+1, Diego Mijelshon wrote:

>>>>> Both of your examples are for inserts.
>>>>> In neither case the instantiation location is important (you can try)
>>>>> In neither case the object is a proxy, nor would it have to be even if
>>>>> it was already persistent.
>>>>> And in both cases, trying to update the object afterwards with just a
>>>>> TransactionScope would not work.

>>>>> Just accept that it's not technically feasible for NH (or any other
>>>>> framework) to do what you want, nor is it desirable for most people using
>>>>> it. Completing a scope and flushing a unit of work are different things.

>>>>>     Diego

>>>>> On Mon, Apr 16, 2012 at 12:34, John T wrote:

>>>>>> Please re-read my examples.

>>>>>> The error in your example is that "foo" is instantiated outside of
>>>>>> the TransactionScope. In both of my examples the equivalent query occurs
>>>>>> INSIDE the TransactionScope.

>>>>>> either way, given that "foo" will be an instance of an NHibernate
>>>>>> proxy, Yes indeed: why couldn't NHibernate know it is in a TransactionScope
>>>>>> ?!

>>>>>> Regards,
>>>>>> J.

>>>>>> On Monday, April 16, 2012 3:00:50 PM UTC+1, Diego Mijelshon wrote:

>>>>>>> Then, how would you handle this?

>>>>>>>     var session = GetSession();
>>>>>>>     var foo = session.Query<Foo>(...);
>>>>>>>     using (var transactionScope = new TransactionScope())
>>>>>>>     {
>>>>>>>         foo.Bar = newValue;
>>>>>>>         transactionScope.Complete();
>>>>>>>     }

>>>>>>> The update could never happen as there's no way for NH to catch the
>>>>>>> change.
>>>>>>> I't likely the same with other frameworks like EF; if you don't call
>>>>>>> SaveChanges (which is the method that creates the transaction, flushes and
>>>>>>> commits), completing the scope will do nothing.

>>>>>>>     Diego

>>>>>>> On Mon, Apr 16, 2012 at 10:16, John T wrote:

>>>>>>> .. which is the crux of this problem/discussion. There should be,
>>>>>>>> because it is used within a TransactionScope, and when the TransactionScope
>>>>>>>> completes - so should NHibernate.

>>>>>>>> On Monday, April 16, 2012 1:56:32 PM UTC+1, Diego Mijelshon wrote:

>>>>>>>>> The former would probably persist if you flushed the session. The
>>>>>>>>> problem is, there's absolutely nothing telling NH to save the changes to
>>>>>>>>> the DB.

>>>>>>>>>     Diego

>>>>>>>>> On Mon, Apr 16, 2012 at 07:20, John T wrote:

>>>>>>>>>> Hi, The example code in my original post is a perfect example.
>>>>>>>>>> The former doesn't persist, and the latter does.

>>>>>>>>>> Regards,
>>>>>>>>>> J.

>>>>>>>>>> On Saturday, April 14, 2012 7:50:51 PM UTC+1, James Kovacs wrote:

>>>>>>>>>>> I'm confused by your assertion. I have used NHibernate in
>>>>>>>>>>> production
>>>>>>>>>>> applications using TransactionScope for transaction management.
>>>>>>>>>>> NHibernate properly enlisted in the ambient transaction. There
>>>>>>>>>>> was no
>>>>>>>>>>> need to call session.BeginTransaction()/tx.Commit() as well as
>>>>>>>>>>> new
>>>>>>>>>>> TransactionScope()/scope.Complete(). Just the latter was
>>>>>>>>>>> sufficient
>>>>>>>>>>> for proper transaction semantics. Are you using NHibernate 3.2?
>>>>>>>>>>> Can
>>>>>>>>>>> you provide a test case demonstrating the issue that you're
>>>>>>>>>>> seeing?

>>>>>>>>>>> James

>>>>>>>>>>> On Apr 13, 4:56 am, John T wrote:
>>>>>>>>>>> >  Hi group,

>>>>>>>>>>> > so I've discovered that NHibernate does not integrate at all
>>>>>>>>>>> well with the
>>>>>>>>>>> > Ambient Transaction. In fact, when using NHibernate within a
>>>>>>>>>>> > TransactionScope, one would be forgiven for thinking it
>>>>>>>>>>> doesn't integrate
>>>>>>>>>>> > at all.

>>>>>>>>>>> > What should be the correct usage:

>>>>>>>>>>> > public void Foo()
>>>>>>>>>>> > {
>>>>>>>>>>> >    ISession session = null; // get session from wherever

>>>>>>>>>>> >    using (var transactionScope = new TransactionScope())
>>>>>>>>>>> >    {
>>>>>>>>>>> >      session.Save(new PersistableObject { ArbitraryProperty =
>>>>>>>>>>> "a value" });
>>>>>>>>>>> >      transactionScope.Complete();
>>>>>>>>>>> >    }

>>>>>>>>>>> > }

>>>>>>>>>>> > is completely useless. What you actually have to do is:

>>>>>>>>>>> > public void Foo()
>>>>>>>>>>> > {
>>>>>>>>>>> >    ISession session = null; // get session from wherever

>>>>>>>>>>> >    using (var transactionScope = new TransactionScope())
>>>>>>>>>>> >    using (var transaction = session.BeginTransaction())
>>>>>>>>>>> >    {
>>>>>>>>>>> >      session.Save(new PersistableObject { ArbitraryProperty =
>>>>>>>>>>> "a value" });
>>>>>>>>>>> >      transaction.Commit();
>>>>>>>>>>> >      transactionScope.Complete();
>>>>>>>>>>> >    }

>>>>>>>>>>> > }

>>>>>>>>>>> > So the fact that NHibernate has any integration with the
>>>>>>>>>>> Ambient
>>>>>>>>>>> > Transaction seems completely pointless.

>>>>>>>>>>> > Now, I've looked (only cursory thus far) through the NHib src
>>>>>>>>>>> and have
>>>>>>>>>>> > noted a few areas of interest wrt to integrating with the
>>>>>>>>>>> Ambient
>>>>>>>>>>> > Transaction. But I want to ask if anyone has tried this
>>>>>>>>>>> already, and hit
>>>>>>>>>>> > any barriers along the way?

>>>>>>>>>>> > Regards,
>>>>>>>>>>> > John.