Can you reproduce this with a test? I am not following.
On Tue, Sep 9, 2008 at 4:14 PM, Craig Neuwirt <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Sep 9, 2008 at 7:41 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote:
>
>> You are inserting into Foo, that cause invalidation of the cache for them
>>
>
> Yes, in the test I initially submitted I was doing some inserts. I have
> thereafter removed the insert (already in db) and ran the same query twice
> with SetCachable(true) and it did not pull from the cache on the second
> query.
>
>
>>
>> On Tue, Sep 9, 2008 at 7:18 AM, Craig Neuwirt <[EMAIL PROTECTED]> wrote:
>>
>>> Ok, maybe I am confused Ayende,
>>>
>>> I am not updating any Foos. I simply want to perform a query against
>>> Foos already in the db. i want that query cache so that the next time I
>>> execute that same query, it will load it from the cache. These types of
>>> scenarios are very common for entities representing choice tables since they
>>> will never change or be updated.
>>>
>>> Does this make sense? I used to do this successfully during the
>>> NHiberate 1.x era.
>>> Thanks for your patience in helping me out on this issue.
>>> On Tue, Sep 9, 2008 at 1:02 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote:
>>>
>>>> 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
-~----------~----~----~----~------~----~------~--~---
