Hi Jason, Thanks!
I've done the reads in an own transaction. So, one ISession starts tx1 for the reads, then closes the tx. Then changed the targeted object. Then started tx2 and tried to Refresh(...) the targeted object. => results is again a database hit, even if the object is in level 2 cache. This might be by design, but I'm hoping for an alternative solution to my problem. On Apr 30, 1:12 pm, Jason Dentler <[email protected]> wrote: > NH requires an NH transaction for nearly all interaction with the session, > even simple gets, loads, and queries. Anything less means you aren't using > the 2nd level cache correctly. Yes, you can split these in to separate > transactions if necessary, but they should be inside explicit NH > transactions. > > You want to abandon changes to an entity instance and revert back to the > data in the 2nd level cache using the same instance. If refresh forces a db > hit, I don't think this is possible. Still, based on your other comments, it > could be that you don't have Refresh inside an NH transaction and are > therefore bypassing the 2nd level cache. > > I'm not sure what the expected behavior is for Refresh with the 2nd level > cache when it's used properly. > > Thanks, > Jason > > > > > > On Fri, Apr 30, 2010 at 6:24 AM, John Davidson <[email protected]> wrote: > > 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]<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 > 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]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
