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. > > > > > > Operations are mostly based on sql queries. In database data are ok. > > > > > > But by some strange reason nhibernate uses cached old data. > > > > > > Operations are described like following: > > > > > > <class name="Message" table="Messages" > > > > > > > <id name="Id" type="Int32" column="Id"> > > > > > > <generator class="identity"/> > > > > > > </id> > > > > > > <property name="Subject" column="Subject" > > > > > > type="String"/> > > > > > > <property name="CategoryId" column="CategoryId" > > > > > > type="Int32"/> > > > > > > > <sql-query name="Message.Delete"> > > > > > > <synchronize table="Messages"/> > > > > > > UPDATE Messages > > > > > > SET CategoryId = ( /* long select to decide to which category > > > > > > to > > > > > > move*/ > > > > > > ) > > > > > > WHERE Id = :messageId > > > > > > </sql-query> > > > > > > > <sql-query name="Message.GetDetails"> > > > > > > <return alias="msg" class="Message"/> > > > > > > SELECT {msg.*} > > > > > > FROM Messages {msg} > > > > > > WHERE msg.Id = :messageId > > > > > > </sql-query> > > > > > > > when calling delete/update query I use syntax like following > > > > > > using (ITransaction trans = _session.BeginTransaction()) > > > > > > { > > > > > > IQuery query = > > > > > > _session.GetNamedQuery("Message.Delete"); > > > > > > query.SetParameter<IdT>(paramName, id); > > > > > > query.ExecuteUpdate(); > > > > > > trans.Commit(); > > > > > > > _session.Flush(); > > > > > > } > > > > > > when calling read: > > > > > > IQuery query = _session.GetNamedQuery("Message.GetDetails"); > > > > > > query.SetInt32("messageId", messageId); > > > > > > query.List<Message>(); > > > > > > > Session is the same betwwen calls. Caching occurs somewhere inside > > > > > > NHibernate.Loader > > > > > > > obj = session.GetEntityUsingInterceptor(key); > > > > > > -- > > > > > 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. -- 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.
