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. >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >
