Re: [hibernate-dev] @FullTextFilterDef cache
--
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>