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