i'm not sure I see the connection. whether it's dynamic or static, mapped or not, queries and commands can be separated at an infrastructure level to alleviate the problems as the business level.
On Oct 2, 4:44 pm, Yauhen <[email protected]> wrote: > On Oct 1, 7:03 pm, Jason Meckley <[email protected]> wrote:> I come back > to the separation of queries and commands. > > So usually you use something like this? > using(var session = factory.OpenSession()) > { > session....ExecuteUpdate(); > > } > > using(var session = factory.OpenSession()) > { > var entity session..Get<Entity>(id); > ... > > } > > will go a long way to help alleviate the issue. NH deals with objects, > > not tables/rows. the id of an object is a database artifact within the > > domain model. that is why you evict by object rather than id. I also > > convert the sql query to domain logic. > > In my case there are a lot of dynamic: dynamic paged lists, with usr > definied sort column, filter column, filter type. > Also updates logic includ access to a lot of auxilary tables for which > I don't want to create business objects (as they could be used as > filters only in several queries) > > >this would mean the object gets > > updated first, then changes are persisted to the database. again > > removing the issue of 2nd db hits and eviction. > > > This will be your best option to work with the concepts of NH, rather > > than against them. > > > On Oct 1, 9:15 am, Yauhen <[email protected]> wrote: > > > > Let me clarify slightly :) > > > Sometimes I have this sequence > > > 1) > > > session open > > > session get (hit db) > > > session update > > > session get (hit db) > > > > and > > > some times this one > > > 2) session open > > > session update > > > session get (hit db) > > > > In 2nd case first session get (hit db) is missing. > > > Command (session update ) lies inside separate method > > > MessagesRepository.Delete. > > > So I was thinking of some type of uniform. So in both cases I will > > > need to just call MessagesRepository.GetDetails. > > > But in 1st this is not true. Because I will need to do Evict. I was > > > thinking to place it inside MessagesRepository.Delete. > > > But it is not possible to do this by id. Of course I could write to > > > methods - MessagesRepository.Delete(id), > > > MessagesRepository.Delete(entity) and in 2nd do Evict. 2nd will be > > > used in 1) sequence of commands. As I understand the most simple way > > > to > > > do 1) without evict is using separate sessions. But I was thinking > > > before that sharing the same session will be more correct for > > > performance. > > > So my implementation was based on NHibernate Best Practices with > > > ASP.NET, 1.2nd Ed.(http://www.codeproject.com/KB/architecture/ > > > NHibernateBestPractices.aspx) > > > > On Oct 1, 4:01 pm, Jason Meckley <[email protected]> wrote: > > > > > in that scenario there is no need to evict, because no entities have > > > > been loaded. it may be that execute update works like save/update/ > > > > delete/etc. calling the method queues the command. it's not actually > > > > executed until the session is flushed. example > > > > > session open > > > > session update (update is queued) > > > > session get (hit db) > > > > tx.commit/session.flush (update is executed) > > > > > if that's the case it would explain why you are getting "stale" data. > > > > > Something else to consider is the session/unit of work boundaries and > > > > practice of command query separation. I have used this with great > > > > success without fail. In the context of NH a session should have the > > > > purpose of getting data (query) or modifing data (command), not both. > > > > in the context we described we have queries and commands. > > > > > at a minimum this should work > > > > using(var session = factory.OpenSession()) > > > > { > > > > using(var tx = session.BeginTransaction()) > > > > { > > > > session....ExecuteUpdate(); > > > > tx.Commit(); //omitting rollback code, but it should be there > > > > } > > > > using(var tx = session.BeginTransaction()) > > > > { > > > > var entity session..Get<Entity>(id); > > > > Display(entity); > > > > tx.Commit(); //omitting rollback code, but it should be there > > > > } > > > > > } > > > > > typically I wouldn't write the code this way either, unless I was > > > > stuck using webforms. instead I would write it like this > > > > using(var session = factory.OpenSession()) > > > > using(var tx = session.BeginTransaction()) > > > > { > > > > session....ExecuteUpdate(); > > > > tx.Commit(); //omitting rollback code, but it should be there > > > > > } > > > > > using(var session = factory.OpenSession()) > > > > using(var tx = session.BeginTransaction()) > > > > { > > > > var entity session..Get<Entity>(id); > > > > Display(entity); > > > > tx.Commit(); //omitting rollback code, but it should be there > > > > > } > > > > > where each of those would be it's own request. in web MVC it's > > > > referred to as Post-Redirect-Get. the concept of query command > > > > separation would apply to rich clients or messsaging as well. the > > > > implementation may look different though. > > > > > On Oct 1, 3:14 am, Yauhen <[email protected]> wrote: > > > > > > I am speaking about your scenario: > > > > > session open > > > > > session get (hit db) > > > > > session update > > > > > session evict (if you don't evict get pulls for 1st level cache) > > > > > session get (hit db) > > > > > > I want that it looks like > > > > > session open > > > > > session update > > > > > session evict (by it without database hit) > > > > > session get (hit db) > > > > > > So I want some way to evict from 1st level cache by id. > > > > > > On Sep 30, 8:26 pm, Jason Meckley <[email protected]> wrote: > > > > > > > I don't follow. may be I should back up. > > > > > > what are you doing now? is it the code your originally posted? if > > > > > > not > > > > > > please post the actual code. > > > > > > what is happening? > > > > > > what do you want/expect to happen? > > > > > > what do you mean by cache? 1st level cache. also known as the > > > > > > identity > > > > > > map. or are you referring to 2nd level cache? > > > > > > I assume the 1st level cache, since you don't have caching enabled > > > > > > in > > > > > > the mapping. > > > > > > > if the entity exists in the 1st level cache and you query the > > > > > > database, but the object already exists in the cache the cached > > > > > > object > > > > > > is returned, not the database object. have you run your application > > > > > > through nhprof? this will give you an excellent idea of what's going > > > > > > on. > > > > > > > On Sep 30, 11:25 am, Yauhen <[email protected]> wrote: > > > > > > > > Are there any way to do without additional hit on database? For > > > > > > > example to make evict by id? > > > > > > > Because first get seen to me redundant. I need only updated > > > > > > > entity not > > > > > > > original. And method should be as > > > > > > > > session get (hit db) > > > > > > > session update > > > > > > > session evict (if you don't evict get pulls for 1st level cache) > > > > > > > > On Sep 30, 5:58 pm, Jason Meckley <[email protected]> wrote: > > > > > > > > > if the next call comes from the same session, then you need to > > > > > > > > evict > > > > > > > > the object. example: > > > > > > > > session open > > > > > > > > session get (hit db) > > > > > > > > session update > > > > > > > > session evict (if you don't evict get pulls for 1st level cache) > > > > > > > > session get (hit db) > > > > > > > > > if the the call comes from a completely different session then > > > > > > > > you > > > > > > > > don't need to do anything. > > > > > > > > session 1: open > > > > > > > > session 2: open > > > > > > > > session 2: get (hit db) > > > > > > > > session1: update > > > > > > > > session2: get (1st level cache) > > > > > > > > this is by design > > > > > > > > > if you are expecting this: > > > > > > > > session 1: open > > > > > > > > session 2: open > > > > > > > > session 2: get (hit db) > > > > > > > > session1: update > > > > > > > > session2: get (hit db) > > > > > > > > ... > > > > > > > > it won't, not without evicting anyway. that is by design. there > > > > > > > > are 3 > > > > > > > > options to handle that > > > > > > > > 1. pessimistic concurrency (lock the database row) > > > > > > > > 2. optimistic concurrency (versioning) > > > > > > > > 3. call evict on session 2 > > > > > > > > > typically #2 provides better performance. it requires you to > > > > > > > > handle > > > > > > > > the StaleObjectException. #1 can result in command timeouts, so > > > > > > > > you > > > > > > > > would need to handle them as well. #3 goes against how NH is > > > > > > > > designed > > > > > > > > to operate. it's possible, but not advisable. also you cannot > > > > > > > > guarantee evict is called before session 1 update. > > > > > > > > > On Sep 30, 10:32 am, Yauhen <[email protected]> wrote: > > > > > > > > > > I simply need invalidate cache. So next call not get value > > > > > > > > > fro cache > > > > > > > > > but from real database. > > > > > > > > > > On Sep 30, 5:27 pm, Roger Kratz <[email protected]> > > > > > > > > > wrote: > > > > > > > > > > > I'm not sure I understand but... > > > > > > > > > > > << [...] Session is the same betwwen calls. [...]>> > > > > > > > > > > << [...] query.ExecuteUpdate(); [...] >> > > > > > > > > > > > Are you expecting your call to ExecuteUpdate to update the > > > > > > > > > > state inside your ISession? I don't think that will work. > > > > > > > > > > > Session keeps a first level cache. The state of this cache > > > > > > > > > > won't be updated when calling ExecuteUpdate AFAIK - no > > > > > > > > > > entities are returned. > > > > > > > > > > > /Roger > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: [email protected] > > > > > > > > > > [mailto:[email protected]] On Behalf Of Yauhen > > > > > > > > > > Sent: den 30 september 2010 16:10 > > > > > > > > > > To: nhusers > > > > > > > > > > Subject: [nhusers] Re: NHibernate cache > > > > > > > > > > > so nobody has ideas? > > > > > > > > > > > On Sep 28, 12:50 pm, Yauhen <[email protected]> wrote: > > > > > > > > > > > I have found very strange effect when using nhibernate. > > > > > > > > > > > I am trying to do one clever update operation. Then read > > > > > > > > > > > saved data > > > > > > > > > > > from database. > > ... > > read more » -- 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.
