nice!
On Tue, Sep 9, 2008 at 11:30 AM, Will Shaver <[EMAIL PROTECTED]> wrote:
> I do this in my custom interceptor:
>
> public class CustomInterceptor : EmptyInterceptor
> {
> private ISession session;
>
> public override bool OnFlushDirty(object entity, object id, object[]
> currentState, object[] previousState, string[] propertyNames, IType[]
> types)
> {
> if (session.Transaction == null || session.Transaction.IsActive == false
> )
> throw new InvalidOperationException("No object updates allowed
> outside of a transaction.");
> }
>
> public override bool OnSave(object entity, object id, object[] state,
> string[] propertyNames, IType[] types)
> {
> if (session.Transaction == null || session.Transaction.IsActive == false
> )
> throw new InvalidOperationException("No object updates allowed outside
> of a transaction.");
> }
>
> public override void SetSession(ISession session)
> {
> base.SetSession(session);
> this.session = session;
> }
> }
>
> On Tue, Sep 9, 2008 at 9: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
-~----------~----~----~----~------~----~------~--~---
