You can use TS but for best stability you must also use (and commit) NH transactions inside TS.
/Oskar 2015-01-07 18:49 GMT+01:00 Dawid Ciecierski <[email protected]>: > Thanks for chipping in. So are you suggesting that my understanding of how > things should work (parent being saved before new child entities belonging > to its collection are inserted) is correct and that it could simply be > TransactionScope-related weirdness getting in the way? Will try to find time > later today to test this on good old Sessions and perhaps come back with a > sample solution if NH still does not behave "correctly". > > Regards, > Dawid > > > On Wednesday, January 7, 2015 6:38:17 PM UTC+1, Ricardo Peres wrote: >> >> TransactionScope has some (OK, a lot of) problems with NHibernate... >> https://nhibernate.jira.com/browse/NH-3568?jql=labels%20%3D%20TransactionScope >> >> RP >> >> On Wednesday, January 7, 2015 4:32:08 PM UTC, Dawid Ciecierski wrote: >>> >>> Thank you for your reply. No, we don't explicitly call Save or Flush; >>> everything is manages automatically: using new TransactionScope() together >>> with transaction.Complete(). It is indeed the case that Profile is an entity >>> and not a component. However, I believe that such simple collection elements >>> would fall under "collection elements" (step 4), while child entities should >>> be serviced by step 3 + step 5. >>> >>> Regards, >>> Dawid >>> >>> On Wednesday, January 7, 2015 2:20:54 PM UTC+1, Oskar Berggren wrote: >>>> >>>> Are you calling Save() or similar on the new Profile? >>>> >>>> Otherwise, it might be that Profile is an entity and therefore falls >>>> under step 1 in the list. It's possible that step 5 "all collection >>>> insertions" really means the relation records in a many-to-many-table. >>>> >>>> /Oskar >>>> >>>> 2015-01-07 12:04 GMT+01:00 Dawid Ciecierski <[email protected]>: >>>> > Anyone? :-) Still having this problem and not sure how to proceed. >>>> > Will be >>>> > grateful for any and all ideas! >>>> > >>>> > Regards, >>>> > Dawid >>>> > >>>> > >>>> > On Thursday, September 11, 2014 6:30:30 AM UTC+2, Dawid Ciecierski >>>> > wrote: >>>> >> >>>> >> This is a cross-post from StackOverflow, but doing it only because >>>> >> the >>>> >> original question did not get much attention (or answers). The >>>> >> original post >>>> >> can be found here; the gist is summarized below. >>>> >> >>>> >> According to NHibernate documentation, SQL statements are issued in >>>> >> the >>>> >> following order: >>>> >> >>>> >> all entity insertions, in the same order the corresponding objects >>>> >> were >>>> >> saved using ISession.Save() >>>> >> all entity updates >>>> >> all collection deletions >>>> >> all collection element deletions, updates and insertions >>>> >> all collection insertions >>>> >> all entity deletions, in the same order the corresponding objects >>>> >> were >>>> >> deleted using ISession.Delete() >>>> >> >>>> >> We have two entities, Client and Profile, where Client owns and is >>>> >> solely >>>> >> responsible for its child collection of Profiles. Client makes use of >>>> >> versioning. Via session interceptors we ensure that its version field >>>> >> is >>>> >> marked as dirty whenever its child collection changes. According to >>>> >> the >>>> >> above order, when a new Profile is added to Client we should see an >>>> >> SQL >>>> >> UPDATE for Client changing the version, and then an SQL INSERT for >>>> >> the new >>>> >> Profile. However, the following actually happens as observed via >>>> >> ExpressProfiler: >>>> >> >>>> >> SELECT Id, Version >>>> >> FROM Clients >>>> >> WHERE Id='3F08F098-09C8-CE42-9594-39C9EAA21B64' >>>> >> SELECT ClientId, ProductId, Score, Comment >>>> >> FROM ClientProfiles >>>> >> WHERE ClientId='3F08F098-09C8-CE42-9594-39C9EAA21B64' >>>> >> INSERT INTO ClientProfiles (Comment, Score, ClientId, ProductId) >>>> >> VALUES ('some comment', 123, >>>> >> '3F08F098-09C8-CE42-9594-39C9EAA21B64', >>>> >> '487BC856-6EAF-42E2-ADD6-B3DE056EA714') >>>> >> UPDATE Clients SET Version = 46 WHERE Id = >>>> >> '3F08F098-09C8-CE42-9594-39C9EAA21B64' AND Version = 45 >>>> >> >>>> >> The fact that the INSERT happens before the UPDATE is undesirable in >>>> >> our >>>> >> case as the infrastructure expects a StaleObjectStateException in >>>> >> case >>>> >> optimistic concurrency finds two processes modifying the same data. >>>> >> We don't >>>> >> really see why the order does not seem to follow documentation. Hence >>>> >> hoping >>>> >> that NH masters will have more ideas as to why this is happening! >>>> >> Will be >>>> >> grateful for any and all input that brings us a little closer to a >>>> >> solution. >>>> >> >>>> >> (Class definitions and mappings can be found on StackOverflow.) >>>> >> >>>> >> Regards, >>>> >> Dawid Ciecierski >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> > Groups >>>> > "nhusers" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> > an >>>> > email to [email protected]. >>>> > To post to this group, send email to [email protected]. >>>> > Visit this group at http://groups.google.com/group/nhusers. >>>> > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nhusers. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/d/optout.
