Hi Henrik, I replied earlier on this morning but it seems to have disappeared into the ether, so apologies if duplicate messages appear.
I would say that an ISession with a per-transaction lifestyle would sometimes be useful here, but not always. Several reasons why you wouldn't want it: 1) In webbaps it is often useful to have the Nhibernate ISession span the whole http request. The stops problems with lazy-loading, and also allows you to take advantage of the 1st level cache. 2) One ISession per-transaction could sometimes lead to the "session- per-operation" anti pattern. In those webapps where you do want one ISession for each http request, just marking transactions as readonly does the job. regards, Jordan. On Apr 20, 2:41 pm, Henrik <[email protected]> wrote: > Hi, > > No problems! > > https://github.com/haf/Castle.Services.Transaction/tree/develop/src/C...https://github.com/haf/Castle.Facilities.NHibernate/blob/master/src/C... > > I see -- in that case, perhaps a 'nice' solution would be an ISession > component with Per-Transaction lifestyle and a custom > IComponentActivator? I haven't hacked Windsor too much, but the new > NHibernateFacility revolves around IoC rather than registering > resources. Perhaps someone could advice if an IComponentActivator > implementation is the correct way to go if FlushMode were to be set > when a readonly transaction is resolved? Probably the per-transaction > lifestyle would have to move all of its CustomContext keys to the > creation context's keys: > > public interface IComponentActivator > { > object Create(CreationContext context); > void Destroy(object instance); > > } > > hmm.. > > Cheers > Henrik > > On Apr 19, 5:57 pm, Jordan <[email protected]> wrote: > > > > > > > > > Hello Henrik, > > > Many thanks for looking at this. I've replied inline to your comments: > > > > I have added a property called 'CustomContext : > > > IEnumerable<KeyValuePair<string,object>>', > > > Ah cool - sounds good. > > > > As far as I understand, your patch only > > > introduced this property but didn't add the infrastructure required > > > for NHibernate to make use of it? Is that correct? > > > No - I also provided the necessary patch for NHibernate to make use of > > it. Basically, the ResourceAdapter > > sets the FlushMode to FlushMode.Never for the course of the > > transaction, and then back to its previous setting once > > the transaction had been > > committed.https://github.com/gusgorman/Castle.Facilities.NHibernateIntegration > > > > In that case, perhaps you would be interested in adding those features > > > to the current develop branch of C.S.Transaction and also create a > > > wiki page on the new NHibernateFacility... > > > Yes - I'm quite busy at the moment but will definitely try to find the > > time. > > > > PS: Isn't the new per-transaction lifestyle better for fixing this > > > NHibernate problem of read-after-faulted-write? > > > Um - not sure, can you point me at the docs for the new per- > > transaction lifestyle, I'm not familiar with it. > > > regards, > > Jordan. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
