Henry; you are right. In my e-mail, to clarify; IHandlerSelector may also select an ISession- per-request IF there's a read-only transaction ongoing!
On Apr 29, 4:37 pm, Henry Conceição <[email protected]> wrote: > But the Session is not only used for caching of loaded entities. It > can handle other things like batching, dirty checking, etc. > > Cheers, > Henry Conceição > > > > > > > > On Fri, Apr 29, 2011 at 2:31 AM, Henrik Feldt <[email protected]> wrote: > > 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... > > 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 > > athttp://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.
