You haven't given any reason why it would be hard or impossible to implement in NH.
Thank you for your input none the less. Regards, J. On Monday, April 16, 2012 7:25:35 PM UTC+1, Diego Mijelshon wrote: > > 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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
