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