Hello Erik,
Monday, September 15, 2003, 4:27:27 PM, you wrote:
EH> On Monday, September 15, 2003, at 09:45 AM, Bruce Ritchie wrote:
>> I would suggest *not* using caching inside of filters provided by
>> lucene but rather provide a wrapper to do the caching. The reason is
>> that some applications really don't want the libraries they use to be
>> a source of concern for memory usage. i.e. if I search for a string
>> using 10,000 different date filters (an extreme example, but possible)
>> I want the ability to control how those bitsets are going to be > cached.
EH> In the case of QueryFilter, simply construct a new one to avoid caching
EH> rather than reuse the same instance. So you have control there as
EH> well. The only thing that is cached is a BitSet, so it should be much
EH> of a memory usage concern.
>> public class CachedFilter extends Filter {
>> BitSet bits;
>> Filter filter;
>>
>> public CachedFilter(Filter filter) {
>> this.filter = filter;
>> this.bits = null;
>> }
>>
>> public BitSet bits(IndexReader reader) throws IOException {
>> if (bits != null) {
>> return bits;
>> }
>>
>> bits = filter.bits(reader);
>> return bits;
>> }
>> }
EH> You would have problems if you searched a different index or different
EH> instance of IndexReader even with your caching here. You should cache
EH> like QueryFilter does to avoid a potential mismatch with IndexReader
EH> instances.
EH> But you're implementation is exactly what I was envisioning with the
EH> added WeakHashMap of QueryFilter.
EH> Erik
EH> ---------------------------------------------------------------------
EH> To unsubscribe, e-mail: [EMAIL PROTECTED]
EH> For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Maxim mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
