I think it is working as expected :-)  I performed explcit insert to test
the scenario in which the data is in the db already and not created as a
result of a Save.  I then peformed a query, deleted the data, performed
another query and the results came back,

I guess my main problem was pollution of the test initially when I was
performing a save without a transaction.  I didn't properly consider that
that erroneously affect the state of the second level cache.

Thanks again for your patience and help on this one.  I guess we can close
this issue

Cheers,
  craig

    [Test]
        public void CanQueryFromSecondLevelCache()
        {
            using (ISession s = OpenSession())
            {
                using (IDbCommand command = s.Connection.CreateCommand())
                {
                    command.CommandText = "INSERT INTO Foos
VALUES('Craig')";
                    command.ExecuteNonQuery();
                }
            }

            using (ISession s = OpenSession())
            {
                Foo result = (Foo)s.CreateCriteria(typeof(Foo))
                    .Add(Property.ForName("Name").Eq("Craig"))
                    .SetCacheable(true)
                    .UniqueResult();

                Assert.IsNotNull(result);
            }

            using (ISession s = OpenSession())
            {
                using (IDbCommand command = s.Connection.CreateCommand())
                {
                    command.CommandText = "DELETE FROM Foos";
                    command.ExecuteNonQuery();
                }
            }

            using (ISession s = OpenSession())
            {
                Foo result = (Foo)s.CreateCriteria(typeof(Foo))
                    .Add(Property.ForName("Name").Eq("Craig"))
                    .SetCacheable(true)
                    .UniqueResult();

                Assert.IsNotNull(result);
            }
        }

On Tue, Sep 9, 2008 at 9:25 AM, Ayende Rahien <[EMAIL PROTECTED]> wrote:

> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to