The problem is that you never committed a transaction after updating Foos.
In order to prevent you from seeing uncommitted transactions, NHibernate
will set the invalidation time for all Foos to a minute in the future, so
you will not see the change until you commit.
On commit, it set the invalidation time to the current date.
Because of that, you never get to see the value of the real item from the
cache. The cache check the query date vs. the invalidation date for foo (one
of the tables involves), sees that it is later than that, and conclude that
the query is now invalid.


On Tue, Sep 9, 2008 at 3:04 AM, 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to