I don't know how your application looks like, and if the changes are made outside the session (detached). But - what you are doing here smells a bit. Try to treat it this way:
- consider to map the class using optimistic-lock="dirty", so you only get an exception when the same properties changed. - To avoid concurrency conflicts, lock the objects in the database when you read it. This only works if you change the objects during the lifecycle of a session. - if a StaleObjectException occurs, changes get lost, because there is a unrecoverable conflict. On 21 Jul., 21:29, Fabio Maulo <[email protected]> wrote: > ISessionImplementor InterfaceGet the persistence context for this session > > IPersistenceContext > <mk:@MSITStore:C:\CSharp\NH2.1.x\nhibernate\build\NHibernate-2.1.0.GA-debug\doc\NHibernateAPI.chm::/html/88fc57a4-e793-db6e-8d7b-a61c749c01ac.htm> > PersistenceContext { get; } > > IPersistenceContext Interface > Holds the state of the persistence context, including the first-level cache, > entries, snapshots, proxies, etc. > > 2009/7/21 Fabio Maulo <[email protected]> > > > > > let me check API doc[?] > > > 2009/7/21 Fabio Maulo <[email protected]> > > > Dirty entities are in the PersistentContext (I don't remember if it is > >> visible from ISession or ISessionImplementor) > >> 2009/7/21 Matt Lund <[email protected]> > > >>> OK... I suspected as much but wanted to be sure... > > >>> So tell me this... Is there some way I can programmatically get the > >>> list of dirty entities from the old session? I looked to see if there > >>> was something like ISession.GetDirtyEntities() but didn't see > >>> something like this. > > >>> I'll tell you why I ask... It seems like I'm dealing with one of two > >>> scenarios when I get a StaleObjectStateException. Scenario A is that > >>> a DB row was modified since I read it but the modified fields are > >>> different from the fields I've modified (there's no conflict). > >>> Scenario B is that a DB row was modified since I read it and once or > >>> more of the modified fields corresponds to a field I've modified (and > >>> the values are different) - this is a conflict. > > >>> It seems like after I get a StaleObjectStateException I could call a > >>> handy method that would: > > >>> 1. Create a new session > >>> 2. For each dirty object in the old session: > >>> a. Read the entity into the new session and determine if > >>> there's a "conflict" (if so, return CONFLICT) > >>> b. Merge the changes made in the db with the changes made in > >>> the old session. > > >>> So in the case of Scenario A I can now continue on my merry way. In > >>> the case of Scenario B I can decide how to deal with the conflicts. > > >>> Does this seem possible? My first step will be to figure out how to > >>> get the collection of dirty entities out of the old session - is there > >>> a way to do this? > > >>> Thanks! > > >>> On Jul 21, 11:32 am, Fabio Maulo <[email protected]> wrote: > >>> > For StaleObjectStateException you should throw the session, open a new > >>> one, > >>> > use session.Merge to reattach entity, continue working. > > >>> > 2009/7/21 Matt Lund <[email protected]> > > >>> > > I did searching on this forum and couldn't find an answer to my > >>> > > question, but my apologies if it's already been answered. > > >>> > > I want to understand how to deal with recovering from a > >>> > > StaleObjectStateException in a simple scenario. > > >>> > > Suppose the following occur in this order. Session 1 is occuring on > >>> > > thread 1 and Session 2 is occuring on thread 2. > > >>> > > 1. Session 1 loads entity a1 of type A, entity b1 of type B, and > >>> > > entity c1 of type C > >>> > > 2. Session 2 loads entity c2 of type C > >>> > > 3. Session 1 modifies properties of a1, b1, and c1 > >>> > > 4. Session 2 modifies properties of c2 > >>> > > 5. Session 2 flushes and commits > >>> > > 6. Session 1 flushes and commits > > >>> > > At step 6 I can clearly expect a StaleObjectStateException. When > >>> this > >>> > > occurs I try to: > > >>> > > 7. Evict c2 from session 1 > >>> > > 8. Load c2 on session 1 > >>> > > 9. Re-apply changes to c2 > >>> > > 10. Flush session 1 > > >>> > > But I get StaleObjectStateException on 10 as well. > > >>> > > So in lieu of the evict/load in steps 7-8 I tried a few other things > >>> > > that didn't work either. I tried a refresh (same outcome). And I > >>> > > tried an evict & refresh (same outcome). > > >>> > > The only success I've had is when, as a result of the > >>> > > StaleObjectStateException on step 6, I clear the session and re-do > >>> > > steps 1,5. > > >>> > > The conclusion I'm reaching is that once I get a > >>> > > StaleObjectStateException, nothing can be done to simply treat c1 and > >>> > > get to a point where I can attempt to flush the session again. Is > >>> > > this the case? > > >>> > -- > >>> > Fabio Maulo > > >> -- > >> Fabio Maulo > > > -- > > Fabio Maulo > > -- > Fabio Maulo > > 360.gif > < 1 KBAnzeigenHerunterladen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
