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
