On 7/30/09 4:10 AM, Michael McCandless wrote:
Plus, the original motivation for this (LUCENE-1195) was because
queries in general look up the same term at least 2 times during their
execution (weight (idf computation), get postings), and so I think we
wanted to ensure that a single thread doing its query would not see
its terms evicted (due to many other threads coming through) by the
2nd time it needed to use them. But if we made the central cache
"large enough", perhaps growing if it detects many threads, then this
(other threads evicted my entries before I finished my query)
shouldn't be a problem in practice.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Yes this was part of the motivation. Especially wildcard or range
queries could wipe out the entire cache before another thread does its
second term lookup.
If we had a lock-less cache then I agree simply making it larger would
probably be better than having separate caches per thread.
Also we should probably optimize the most common cases... if in rare
situations certain queries wipe out the cache it might not be such a big
deal.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
