I've filed the exact same issue about a year ago, but it isn't really
a "bug".  You are actually supposed to use a child session. (ie. var
childSession = @event.Session.GetSession(EntityMode.Poco); ).

The child session will share any transactions & state you need, plus,
it won't throw the error that is causing you the grief.


On Sep 10, 8:19 am, Filip Zawada <[email protected]> wrote:
> I submitted a bug report together with a patch fixing the 
> issue.http://216.121.112.228/browse/NH-2322
>
> I'd be really grateful if somebody could apply it before the 3.0 GA
> release ;).
>
> Thanks,
> Filip Zawada
>
> On 2010-09-03 04:22, Fabio Maulo wrote:
>
> > Ok
>
> > --
> > Fabio Maulo
>
> > El 02/09/2010, a las 20:57, Filip Zawada<[email protected]>  escribi :
>
> >> I posted a message on nhusers but no-one replied. Maybe this
> >> group is a better choice since the post is related to the internals of NH.
> >> The main reason I'm putting it here is that I think the described behavior 
> >> is a bug, and I would like to first confirm it here before creating a JIRA 
> >> ticket.
>
> >> I'm trying to implement an IPostInsert/UpdateEventListener. What I
> >> want to achieve is sending two SQL update queries:
>
> >> void IPostUpdateEventListener.OnPostUpdate(PostUpdateEvent @event)
> >> {
> >>     /*
> >>      * Getting left and right ommited
> >>      */
> >>     @event.Session.CreateSQLQuery("update categories c set
> >> isbranchactive = 1 where c.lft>= :lft and c.rgt<= :rgt")
> >>                         .SetInt64("lft", left)
> >>                         .SetInt64("rgt", right)
> >>                         .ExecuteUpdate();
>
> >> }
>
> >> Nothing special. The problem is it blows up when commiting a
> >> transaction:
>
> >> [InvalidOperationException: Collection was modified; enumeration
> >> operation may not execute.]
> >>    System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource
> >> resource) +56
> >>    System.Collections.Generic.Enumerator.MoveNextRare() +58
> >>    System.Collections.Generic.Enumerator.MoveNext() +93
> >>    NHibernate.Engine.ActionQueue.ExecuteActions(IList list) +149
> >>    NHibernate.Engine.ActionQueue.ExecuteActions() +32
>
> >> NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource
> >> session) +253
>
> >> NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent
> >> event) +97
> >>    NHibernate.Impl.SessionImpl.Flush() +275
> >>    NHibernate.Transaction.AdoTransaction.Commit() +236
>
> >> I looked into the ExecuteActions(...) and replaced foreach enumeration
> >> with a regular for loop.
> >> Everything seems to work just fine. NH tests are passing (tested on 2.1.2).
>
> >> Now my question is: is the original behavior a bug. If yes, then is
> >> the proposed solution acceptable?
>
> >> I need this order of execution and cannot use Pre* Listeners
>
> >> Thanks,
> >> Filip

Reply via email to