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 > > >
thread-safety-nh.patch
Description: Binary data
