I sent that. It was the one where inserting the foo was in tx.
On Tue, Sep 9, 2008 at 7:28 AM, Craig Neuwirt <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
