lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: CachingWrapperFilter: why cache per IndexReader?
Date Wed, 02 Jan 2008 07:03:48 GMT

: I suggest to use instead of reader as key for the 
: WeakHashMap. This way multiple IndexSearcher/IndexReacher instances would 
: share the cache.

setting aside discussion of why you should/shouldn't use a single 
IndexReader, or why the various places in the Lucene code base (like 
CachingWrapperFilter) that maintain caches using WeakHashMaps *were* built 
using the IndexReader as the key instead of, there are 
two fairly practical reasons why it would be a bad idea to try and do 

1) there is a semi-articulated goal of moving away from "under the 
coveres" weakref caching to more explicit and controllable caching ... 
it's not such a big deal in this case since it only comes into play if the 
user uses th eclass -- but it would still be nice if user code had a way 
to actually monitor/manipulate the cache.  (it's a much bigger issue 
with things like FieldCache, see also LUCENE-831)

2) IndexReader implementations are not currently (and have never really 
been) required to return anything useful from the directory() method ... 
in the trunk, classes like MultiReader will throw an UnSupOpEx if 
directory() is called.   in older versions of Lucene, MultiReader would 
return the directory of the first sub IndexReader it was using -- which 
would result in some pretty frustrating cache key collisions if you tried 
to use the directory instead of the IndexReader itself.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message