[hibernate-dev] @FullTextFilterDef cache

[Emmanuel Bernard]

--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com 
  | http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)

On  Sep 5, 2008, at 09:16, Sanne Grinovero wrote:

> The API you propose is looking cleaner and much more self-explanatory;
> still you may help me a bit to understand it better:
>
> as I understood from the reference docs the filter implementation
> has to be reused for BitSet caching to work,
> so does this mean that if my Filter implementation
> is not threadsafe I should use FilterCacheMode.NO,
> and otherwise I have more choice?
> Is this right? we should be more clear on this requirement.

yes that is true, let's open a JIRa issue to make that more clear.

>
>
> I don't really understand the need for "AUTOMATIC/NO/YES",
> if it is possible to reuse the filter (i.e. it is safe) why  
> shouldn't you?

The Filter instance might be obsolete as soon as it is used like a  
querywrapperfilter.
Or the Filter might cache BitSet itsself (by IndexReader) and does not  
need the HSearch BitSet caching layer: it has more precise information  
and the cache gets obsolete before an IndexReader does.
Or your memory level is constrained.

I present a case for each in the book

>
> The filter is linked to the current open IndexReader (right I hope?)

no, but the filter results are.

>
> so the results wouldn't change anyway (and if they did, we would
> break the repeatable-read capabilities of the current transaction).
> So what is the need for having both
> FilterCacheMode.RESULTS and FilterCacheMode.FILTER_INSTANCE ?

across different tx, the underlying IR could be the same (as the  
lucene index has not changed) but still have the cache obsolete  
(because the filter information comes form an external source/service)

>
> After all I think the only information we need is to know if
> the implementation is safe to be reused, or not.
>
> 2008/9/5 Emmanuel Bernard <emmanuel at hibernate.org>:
>> I am thinking about caching and filters.
>> In 3.0, we cache instances of Filter by using  
>> @FullTextFilterDef.cache=true
>> In 3.1, we still can cache instances of Filter using
>> @FullTextFilterDef(cache=true, cacheBitResult= CacheBitResults.NO)
>> an we can cache BitSet results by using  
>> @FullTextFilterDef(cache=true)
>> //, cacheBitResult= CacheBitResults.AUTOMATIC
>> I think we introduced cacheBitResult to keep @FullTextFilterDef  
>> backward
>> compatible. But reality is that this feature is not backward  
>> compatible:
>> - a new layer of caching is automatically added if you keep the  
>> annotation
>> as in 3.0. It probably won't do too much harm but add an unnecessary
>> indirection
>> Fundamentally, it seems that the annotation should be
>> @FullTextFilterDef(cache=FilterCacheMode.RESULTS)
>> @FullTextFilterDef(cache=FilterCacheMode.FILTER_INSTANCE)
>> @FullTextFilterDef(cache=FilterCacheMode.NO)
>> This will force a change from 3.0 apps to 3.1 apps but it's much  
>> clearer.
>> I can't seem to find a compelling reason to have instance caching  
>> and result
>> caching configurable independently.
>> WDYT?
>>
>> --
>> Emmanuel Bernard
>> http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com 
>>  | http://twitter.com/emmanuelbernard
>> Hibernate Search in Action (http://is.gd/Dl1)
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>