James, Thanks for assisting me on this issue. The problem, as you pointed out all along, had to do with performing a save without a tx. It polluted the second level cache so I wasn't testing with the environment I was expecting.
Cheers, craig On Mon, Sep 8, 2008 at 10:39 PM, James Kovacs <[EMAIL PROTECTED]>wrote: > In order for the entity to be saved, you need to commit the tx. In the > test, you should probably purge the 2nd level cache by evicting the > serialized entity. > sessionFactory.Evict(typeof(Foo)); > > will remove all serialized Foo objects from the 2nd level cache. To evict > only one: > > sessionFactory.Evict(typeof(Foo), id); > > James > -- > James Kovacs, B.Sc., M.Sc., MCSD, MCT > Microsoft MVP - C# Architecture > http://www.jameskovacs.com > [EMAIL PROTECTED] > 403-397-3177 (mobile) > > > On Mon, Sep 8, 2008 at 6:04 PM, Craig Neuwirt <[EMAIL PROTECTED]> wrote: > >> Ayende, >> >> Thanks for the feedback. However, I believe the Saving operation is >> polluting the test. I want my test to demonstrate the ability to execute a >> query against EXISTING data in the database and have that query put in the >> query cache so that the next time I execute the same query, it uses the >> cache instead of hitting the db. >> >> So to test this, a Foo needs to be in the db and this part needs to be >> removed >> using (ISession s = OpenSession()) >> using (ITransaction tx = s.BeginTransaction()) >> { >> s.Save(foo); >> tx.Commit(); >> } >> Isn't this the normal way of using the query cache? >> >> thanks. >> craig >> On Mon, Sep 8, 2008 at 3:07 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: >> >>> Blah! >>> We were looking at the wrong spot all along. >>> This test works, I marked the parts that I had to change. >>> >>> Perfectly obvious, when you think of this. >>> You asked NHibernate to create new foo, so it has to put it in the cache >>> and invalidate all Foos until the transaction is commited. >>> It does so by specifying a timeout value of one minute from now (IIRC), >>> which obivously mixes up with the test timing. >>> >>> When the tx is commited, NH can make this visible again, and set it to >>> the current timestamp. >>> >>> >>> [Test] >>> public void DoesNotLoadEntityFromSysCache() >>> { >>> Foo foo = new Foo(); >>> foo.Name = "Craig"; >>> >>> using (ISession s = OpenSession()) >>> using (ITransaction tx = s.BeginTransaction()) >>> { >>> s.Save(foo); >>> tx.Commit(); >>> } >>> >>> using (ISession s = OpenSession()) >>> using( ITransaction tx = s.BeginTransaction()) >>> { >>> Foo result = (Foo)s.CreateCriteria(typeof(Foo)) >>> .Add(Property.ForName("Name").Eq("Craig")) >>> .SetCacheable(true) >>> .UniqueResult(); >>> >>> Assert.IsNotNull(result); >>> tx.Commit(); >>> } >>> >>> using (ISession s = OpenSession()) >>> { >>> using (IDbCommand command = s.Connection.CreateCommand()) >>> { >>> command.CommandText = "DELETE FROM Foos"; >>> command.ExecuteNonQuery(); >>> } >>> } >>> >>> using (ISession s = OpenSession()) >>> using (ITransaction tx = s.BeginTransaction()) >>> { >>> Foo result = (Foo)s.CreateCriteria(typeof(Foo)) >>> .Add(Property.ForName("Name").Eq("Craig")) >>> .SetCacheable(true) >>> .UniqueResult(); >>> >>> Assert.IsNotNull(result); >>> >>> tx.Commit(); >>> } >>> >>> using (ISession s = OpenSession()) >>> using (ITransaction tx = s.BeginTransaction()) >>> { >>> s.Delete("from Foo"); >>> s.Flush(); >>> >>> tx.Commit(); >>> >>> } >>> } >>> >>> On Mon, Sep 8, 2008 at 10:47 PM, Craig Neuwirt <[EMAIL PROTECTED]>wrote: >>> >>>> Yeah, that's what I eluded to on my first post. >>>> >>>> Thanks for letting me know I am not completely crazy yet ;-) >>>> >>>> >>>> On Mon, Sep 8, 2008 at 1:28 PM, Ayende Rahien <[EMAIL PROTECTED]>wrote: >>>> >>>>> I think there is still something funny going on, looks to be related to >>>>> the time stamps that were going on there. >>>>> >>>>> >>>>> >>>>> On Mon, Sep 8, 2008 at 9:20 PM, James Kovacs <[EMAIL PROTECTED] >>>>> > wrote: >>>>> >>>>>> I modified your patch to use transactions and SysCache worked for me >>>>>> as expected. I even debugged through and looked at the contents of the >>>>>> Foos >>>>>> table to verify that the IDbCommand did in fact delete the row. I've >>>>>> since >>>>>> reverted the code, but can re-create it tonight when I get home. >>>>>> James >>>>>> -- >>>>>> James Kovacs, B.Sc., M.Sc., MCSD, MCT >>>>>> Microsoft MVP - C# Architecture >>>>>> http://www.jameskovacs.com >>>>>> [EMAIL PROTECTED] >>>>>> 403-397-3177 (mobile) >>>>>> >>>>>> >>>>>> On Mon, Sep 8, 2008 at 12:16 PM, Craig Neuwirt <[EMAIL >>>>>> PROTECTED]>wrote: >>>>>> >>>>>>> So, was their actually a determination made whether or not SysCache >>>>>>> is working as expected or there is actually a problem. If it is the >>>>>>> former, >>>>>>> can someone please show me how to make it work (you can make updates the >>>>>>> patch I submitted) >>>>>>> >>>>>>> thanks, >>>>>>> craig >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 7, 2008 at 7:02 PM, Ayende Rahien <[EMAIL PROTECTED]>wrote: >>>>>>> >>>>>>>> You have to commit the transaction. >>>>>>>> NH requires transactions for reads as well. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 8, 2008 at 2:53 AM, Craig Neuwirt <[EMAIL PROTECTED]>wrote: >>>>>>>> >>>>>>>>> Hey James, >>>>>>>>> >>>>>>>>> You are absolutely correct. Once I added the transaction, my >>>>>>>>> unit test passed. However, the actual scenario I am trying to get >>>>>>>>> working >>>>>>>>> is assuming data is in the db already and I perform an initial query. >>>>>>>>> I >>>>>>>>> want that result to go into the second level cache so it is retrieved >>>>>>>>> from >>>>>>>>> the cache when the same query is executed. How do I make that >>>>>>>>> happen? I >>>>>>>>> tried putting transaction around the query, but that didn't work and >>>>>>>>> I don't >>>>>>>>> think that should be necessary for reads. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> craig >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 7, 2008 at 5:14 PM, James Kovacs < >>>>>>>>> [EMAIL PROTECTED]> wrote: >>>>>>>>> >>>>>>>>>> I am looking at it right now. Initial investigations... The >>>>>>>>>> problem seems to stem from lack of transaction handling in the test >>>>>>>>>> case. If >>>>>>>>>> rather than flushing the session, you commit a transaction, the >>>>>>>>>> SysCache >>>>>>>>>> returns data appropriately. I'll post more as I find out more. (Just >>>>>>>>>> posting >>>>>>>>>> to save Ayende some time.) >>>>>>>>>> >>>>>>>>>> James >>>>>>>>>> -- >>>>>>>>>> James Kovacs, B.Sc., M.Sc., MCSD, MCT >>>>>>>>>> Microsoft MVP - C# Architecture >>>>>>>>>> http://www.jameskovacs.com >>>>>>>>>> [EMAIL PROTECTED] >>>>>>>>>> 403-397-3177 (mobile) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Sep 7, 2008 at 4:07 PM, Ayende Rahien <[EMAIL >>>>>>>>>> PROTECTED]>wrote: >>>>>>>>>> >>>>>>>>>>> Guys, >>>>>>>>>>> I am going to look at the issue now, will post my results soon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sun, Sep 7, 2008 at 10:44 PM, Gildas <[EMAIL PROTECTED] >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Fabio, I know that I'm still noob in NHibernate and that I may >>>>>>>>>>>> ask >>>>>>>>>>>> stupid questions. I'm sorry if you are bored with this, but >>>>>>>>>>>> well, >>>>>>>>>>>> please understand that I'm just trying to resolve a problem I >>>>>>>>>>>> did not >>>>>>>>>>>> have before upgrading to last NHibernate trunk. >>>>>>>>>>>> >>>>>>>>>>>> Going through Rhino code, I can see that my session is created >>>>>>>>>>>> at each >>>>>>>>>>>> request, so that's not the problem. >>>>>>>>>>>> Anyway, I still don't have any second level cache. Items are >>>>>>>>>>>> updated >>>>>>>>>>>> but never retrieved from it. >>>>>>>>>>>> >>>>>>>>>>>> Can someone check the test case from craig, which is failing and >>>>>>>>>>>> don't >>>>>>>>>>>> use any fancy session management ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> On Sep 7, 8:35 pm, "Fabio Maulo" <[EMAIL PROTECTED]> wrote: >>>>>>>>>>>> > 2008/9/7 Gildas <[EMAIL PROTECTED]> >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > > So I'm going to ask if this is the right way to handle >>>>>>>>>>>> sessions ? From >>>>>>>>>>>> > > what I remember of NHibernate, NH Sessions must not be >>>>>>>>>>>> stored in >>>>>>>>>>>> > > HttpContext.Session. I may not understand the reasons why >>>>>>>>>>>> this done >>>>>>>>>>>> > > like this in UnitOfWorkApplication, maybe for long >>>>>>>>>>>> transactions >>>>>>>>>>>> > > management ? >>>>>>>>>>>> > >>>>>>>>>>>> > Rhino UoW use httpSession only for long conversation... >>>>>>>>>>>> > The NhSession CAN be stored in the httpSession simply because >>>>>>>>>>>> is the "most >>>>>>>>>>>> > simple" way to manage long-conversations. >>>>>>>>>>>> > -- >>>>>>>>>>>> > Fabio Maulo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
