[hibernate-dev] CachingWrapperFilter

[Sanne Grinovero]

Hi Marc,
in theory we apply all the same optimisations as the "Lucene edition",
including the "acceptDocs" Bits as described in LUCENE-1536.

These are the main differences of our implementation:
 - uses the SoftLimitMRUCache rather than a synchronized WeakHashMap
 - uses Soft rather than Weak references
 - we do prevent duplicate computation for the same segments in case
of race conditions to prevent unnecessary CPU usage

Overall I'd expect this to perform better than the Lucene vanilla
version; that's probably not something I could state as an universal
truth but it's reasonable for our kind of integration. For example,
making those keys "weak" rather than "soft" would keep all filter
instances in memory, without any kind of upper bound: yes that might
look like "faster" in a couple of small tests but it's probably not
what you want!

Am I wrong? Please let me know if you've been measuring this and got
to different conclusions.

The drawback of soft keys is of course that in case you need a full gc
for other reasons, your cache is cleared. If that's your problem, we
should discuss about more advanced cache tuning options.

Sanne


On 15 February 2015 at 20:05, Marc Schipperheyn
<m.schipperheyn at gmail.com> wrote:
> Just wondering with Lucene 4 whether the Hibernate CachingWrapperFilter
> should leverage that instead of using its own caching implementation. Given
> the discussion in LUCENE-1536.
>
> I'm not superfamiliar with this part of the code, but it looks like the
> LUCENE-1536 allows optimization at a deeper level.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev