Oops. I meant to post that to the NHdev group.
Personally I like the changes that have been put into NH2 to make it more
foolproof. For example, compiling named HQL queries at startup and throwing
when building your session factory rather than waiting until the query is
run.
James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
[EMAIL PROTECTED]
403-397-3177 (mobile)


On Tue, Sep 9, 2008 at 10:16 AM, Craig Neuwirt <[EMAIL PROTECTED]> wrote:

> Thats probably a good question for the group.   NHibernate lets you get
> away without using transactions sometimes, but you never know if you left it
> in an bad state, like my case.  If they are always required on an save or
> update  it might be nice to enforce that
>
>
> On Tue, Sep 9, 2008 at 11:01 AM, James Kovacs <[EMAIL PROTECTED]>wrote:
>
>> Can we do anything in the code to make this error more obvious? Is there a
>> reason that we can't throw an exception if we try to load/save entities
>> outside a transaction given that it is required - and changed behaviour from
>> 1.X? I would think that you could throw on a load/get/query outside of a tx
>> and throw if Save/Update/SaveOrUpdate is called without a tx present, though
>> I haven't looked at the code.
>> James
>> --
>> James Kovacs, B.Sc., M.Sc., MCSD, MCT
>> Microsoft MVP - C# Architecture
>> http://www.jameskovacs.com
>> [EMAIL PROTECTED]
>> 403-397-3177 (mobile)
>>
>>
>> On Tue, Sep 9, 2008 at 9:02 AM, Craig Neuwirt <[EMAIL PROTECTED]> wrote:
>>
>>> Absolutely.... :-)
>>>
>>>
>>> On Tue, Sep 9, 2008 at 10:00 AM, Ayende Rahien <[EMAIL PROTECTED]>wrote:
>>>
>>>> Can I expect a blog post out of this?
>>>>
>>>>
>>>> On Tue, Sep 9, 2008 at 5:56 PM, Craig Neuwirt <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> James,
>>>>>
>>>>> Thanks for assisting me on this issue.  The problem, as you pointed out
>>>>> all along, had to do with performing a save without a tx.  It polluted the
>>>>> second level cache so I wasn't testing with the environment I was 
>>>>> expecting.
>>>>>
>>>>> Cheers,
>>>>>  craig
>>>>>
>>>>>
>>>>> On Mon, Sep 8, 2008 at 10:39 PM, James Kovacs <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> In order for the entity to be saved, you need to commit the tx. In the
>>>>>> test, you should probably purge the 2nd level cache by evicting the
>>>>>> serialized entity.
>>>>>> sessionFactory.Evict(typeof(Foo));
>>>>>>
>>>>>> will remove all serialized Foo objects from the 2nd level cache. To
>>>>>> evict only one:
>>>>>>
>>>>>> sessionFactory.Evict(typeof(Foo), id);
>>>>>>
>>>>>> 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 6:04 PM, 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