[ 
https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978480#action_12978480
 ] 

Shay Banon commented on LUCENE-2474:
------------------------------------

Right, I was thinking that its a low level API that you can just add it to the 
low level readers, but I agree, it will be nicer to have it on the high level 
as well. Regarding the close method name, I guess we can name it similar to the 
FieldCache one, maybe purge?

> We've talked before about putting caches directly on the readers - that still 
> seems like the most straightforward approach?

not sure I understand that. Do you mean getting FieldCache into the readers? 
And then what about cached filters? And other custom caching constructs that 
rely on the same mechanism as the CachingWrapperFilter? 

I think that if one implements such caching, its an advance enough feature 
where you should know how to handle deletes and other tidbits (if you need to).

> We really need one cache that doesn't care about deletions, and one cache 
> that does.

Isn't that up to the cache to decide? That cache can be anything (internally 
implemented in Lucene or externally) that follows the mechanism of caching 
based on (segment) readers. As long as there are constructs to get the deleted 
docs to handle deletes (for example), then the implementation can use it.



> Allow to plug in a Cache Eviction Listener to IndexReader to eagerly clean 
> custom caches that use the IndexReader (getFieldCacheKey)
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2474
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2474
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Shay Banon
>         Attachments: LUCENE-2474.patch
>
>
> Allow to plug in a Cache Eviction Listener to IndexReader to eagerly clean 
> custom caches that use the IndexReader (getFieldCacheKey).
> A spin of: https://issues.apache.org/jira/browse/LUCENE-2468. Basically, its 
> make a lot of sense to cache things based on IndexReader#getFieldCacheKey, 
> even Lucene itself uses it, for example, with the CachingWrapperFilter. 
> FieldCache enjoys being called explicitly to purge its cache when possible 
> (which is tricky to know from the "outside", especially when using NRT - 
> reader attack of the clones).
> The provided patch allows to plug a CacheEvictionListener which will be 
> called when the cache should be purged for an IndexReader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to