lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: QueryFilter vs CachingWrapperFilter vs RangeQuery
Date Tue, 07 Dec 2004 20:29:57 GMT
: > executes the search, i would keep a static reference to SearchIndexer
: > and then when i want to invalidate the cache, set it to null or create

: design of your system.  But, yes, you do need to keep a reference to it
: for the cache to work properly.  If you use a new IndexSearcher
: instance (I'm simplifying here, you could have an IndexReader instance
: yourself too, but I'm ignoring that possibility) then the filtering
: process occurs for each search rather than using the cache.

Assuming you have a finite number of Filters, and assuming those Filters
are expensive enough to be worth it...

Another approach you can take to "share" the cache among multiple
IndexReaders is to explicitly call the bits method on your filter(s) once,
and then cache the resulting BitSet anywhere you want (ie: serialize it to
disk if you so choose).  and then impliment a "BitsFilter" class that you
can construct directly from a BitSet regardless of the IndexReader.  The
down side of this approach is that it will *ONLY* work if you arecertain
that the index is never being modified.  If any documents get added, or
the index gets re-optimized you must regenerate all of the BitSets.

(That's why the CachingWrapperFilter's cache is keyed off of hte
IndexReader ... as long as you're re-using the same IndexReader, it know's
that the cached BitSet must still be valid, because an IndexReader
allways sees the same index as when it was opened, even if another
thread/process modifies it.)

	class BitsFilter {
           BitSet bits;
           public BitsFilter(BitSet bits) {
           public BitSet bigs(IndexReader r) {
             return bits.clone();


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

View raw message