It does not matter what the UoW pattern says about data read. You _REALLY_ need to put a read action in a NHibernate transaction if you want to improve performance. Not having your reads in a transaction may be why you need a second level cache (to compensate for not following the specified rules). Most of the transactional databases now wrap a read action in an ACID transaction on their own, if the request is not already in a transaction - this activity by the database takes more time and resource than if it is done in the application with NHibernate and UoW.
John Davidson On Fri, Apr 30, 2010 at 7:14 AM, tz <[email protected]>wrote: > Thanks for the reply. See my comments inline > > On Apr 29, 8:26 pm, Jason Meckley <[email protected]> wrote: > > I would approach the problem in a completely different manner. > > 1. no long running sessions > > 2. only use 2nd level cache in edge cases as a last resort > > 3. for multi-step operations/commands I would use an intermediate DTO > > to store updates. When the user clicks "save" is when i would alter > > the domain objects. this makes undoing changes much easier. simply > > abandon the DTO. > > I'm not sure whether you do understand my question, but I can't relate > any of your reply to my question. I also don't agree with what you're > saying... > * I don't know what "no long running sessions" would solve for my > issue. All these things you're proposing are a "very complex" way to > do Evict/Load on the same session. > * 2nd level cache is for performance reasons. The issue I'm posting > about is also for performance reasons. So, this cache stays > * Why would I do any object dirty management myself, if nHibernate can > do it for me. > > > > > if you do continue down this path are all your session calls happening > > within a transaction? Proper use of NH dictates that all operations, > > both read and write, should happen within at transaction. This is > > critical for client POIDs, proper UOW management and 2nd level cache. > > > > Again, no answer on my question. Even more, I don't agree with you... > * UoW pattern doesn't say that a read should be in a ACID transaction. > UoW itself is a "business transaction" implementation, which is based > optimistic concurrency ideologies (meaning that you shouldn't keep an > ACID transaction open between the reads and the writes). > > What I want is simply a Update() which does what Evict/Load does, but > not with giving me a new instance. That's all I'd want to know. I know > nH keeps the original state in the session (and the second level > cache), so it shouldn't be that difficult I assume. > > > On Apr 29, 2:05 pm, tz <[email protected]> wrote: > > > > > > > > > > > > > Hi guys, > > > > > I'm working with a long running session which contains all my required > > > data. Further, I use level 2 cache intensively, to cache that > > > information. I let my user edit this data directly using UI controls. > > > > > The user can decide to cancel the modifications, which I though I'd > > > easily solve with performing a ISession.Refresh(..) on the aggregate > > > root of the changed entity. > > > > > However, it turns out that Refresh(...) always goes to the database to > > > refetch the data, even if the data is available in second level cache > > > (tested that the data is there using a second ISession, which returned > > > the data without a database hit). > > > > > Is there a way to refresh entity from data in the second level cache? > > > > > I don't want to use Evict+Load, as I will then get a new instance > > > (Refresh(...) updates the same instance). > > > > > Thanks > > > > > -- > > > 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]<nhusers%[email protected]> > . > > > For more options, visit this group athttp:// > groups.google.com/group/nhusers?hl=en. > > > > -- > > 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]<nhusers%[email protected]> > . > > For more options, visit this group athttp:// > groups.google.com/group/nhusers?hl=en.- Hide quoted text - > > > > - Show quoted text - > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
