Just saw this. 1) Agree, however, that's where I picture that you simply resolve ISession in the c'tor and make the component per request. (I'm not sure about how much the 1st level cache gives you back for using it - a second level cache would still be available and find the id you are querying. Also, NHibernate docs say ISession is cheap and you can make the transaction span all reads. )
My idea is (see roadmap thread) to have a IHandlerSelector that selects the ISession that is not per-transaction, but perhaps per-web-request instead so that you get the best of both worlds, when the ISession isn't resolved in a transaction. Henrik -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jordan Sent: den 21 april 2011 10:38 To: Castle Project Development List Subject: Re: Readonly transactions - yet again. Hi Henrik, Having looked at this it seems to me that in some situations a per- transaction lifestyle would be useful here, but not always. Several reasons why you might not want it: 1) In a webapp it is often desirable to have the Nhibernate ISession open for the whole of the http request, to avoid problems with lazy loading etc. You also get to take advantage of the 1st level cache that the ISession provides. 2) If you have one ISession per transaction you could end up with the "session-per-operation" anti-pattern. In the case where you want the ISession open for the whole of the http request, just marking the necessary 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...http s://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.NHibernateI > > ntegration > > > > 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. -- 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.
