Perhaps the best thing would be to send me your modified test and I will
then see if we are talk apples to apples or apples to oranges.
thanks,
craig
On Tue, Sep 9, 2008 at 6: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
-~----------~----~----~----~------~----~------~--~---
