Session scope state is great... I would introduce it in the past.Ok I'll check the patch.
2009/9/10 Ayende Rahien <[email protected]> > Fabio,Having network problems, can't commit right now. And no, don't ask > me why gmail works as SF doesn't. > I am attaching a patch with my test + a solution. I introduce the notion of > a session scope state, and make use of it to avoid the nasty issues with the > multi threading. > > Steve, > Agree about the need for query plan cache, but we should also be careful > there. It means that we need to start paying attention to what may > potentially be used in multiple threads. > > > On Thu, Sep 10, 2009 at 10:44 PM, Steve Strong <[email protected]> wrote: > >> Came into this a bit late :) Disabling the queryPlanCache entirely is >> probably not an option - as Fabio says, the ANTLR parser is not exactly >> lightweight; with the queryPlanCache in place, this isn't really a problem, >> but without it I think we'd have perf issues. Add to that the additional >> processing that the new Linq provider is doing, and the need for the cache >> is even greater. >> Getting the stateful stuff out into the session would certainly sound like >> a good approach to solving this. >> >> While you're in that code, can you cast your eye over the comment I left >> in regarding the decrementing of i - I don't like that code, since I'm not >> sure it's correct... >> >> >> On 10 Sep 2009, at 21:01, Fabio Maulo wrote: >> >> Well if you define it as no powerful feature I'm supposing you are talking >> about QueryPlanCache. >> Even if we can, in theory, remove the QueryPlanCache using the old parser >> we can't remove it using the ANTLR parse; the ANTLR parse is time hungry. >> >> To transform the QueryPlanCache in "per thread QueryPlanCache" and disable >> it, in web is the same. >> >> 2009/9/10 Ayende Rahien <[email protected]> >> >>> The problem with the query cache as it stands now is that it is a >>> threading hazard.It gives stateful objects to multiple threads. >>> >>> On Thu, Sep 10, 2009 at 9:48 PM, Fabio Maulo <[email protected]>wrote: >>> >>>> 2009/9/10 Ayende Rahien <[email protected]> >>>> >>>>> >>>>> As I see it, we have three options: >>>>> a/ disable the query cache completely >>>>> b/ make the query cache a per thread query >>>>> c/ clone the query from the cache when we give it out >>>>> >>>> >>>> a. When? what you mean ? >>>> >>> >>> Instead of caching things, always create the plan from scratch >>> >>> >>>> remove the query cache mean remove one of the most powerful NH feature >>>> >>> >>> I am not sure that I would call it one of the most powerful features >>> >>> >>>> b. Not viable (if you mean really the query cache) >>>> >>>> I agree, it would nullify much of the advantages. >>> >>> >>>> c. please answer to a and b >>>> >>> >>> answered :-) >>> >>> >>>> -- >>>> Fabio Maulo >>>> >>> >>> >> >> >> -- >> Fabio Maulo >> >> >> > -- Fabio Maulo
