[ 
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542432
 ] 

Ard Schrijvers commented on JCR-1213:
-------------------------------------

"I guess we just have a differing judgment about when and how often the cost of 
building cache entries and maintaining them should be spent." 

I think we have the same end goal: If the index segment instance in which the 
parent lookup was found is still valid --> return cached docNumber. This is the 
main performance we look for. And I also think we agree on the implementation 
regarding the segment instance reference.  I only referred to option (1) as the 
simple first test for valid cache, and then (2). So, in UUIDDocId, I would 
create a weakReference to MultiIndexReader and a seperate one to 
CachingIndexReader (a single segment) . If (1) is valid, you are ready, 
otherwise check (2). If (1) is equally fast as (2) (performance test) I agree 
on removing (1)

I really think we are on the same track, and are talking about the same 
mechanism for maintaining the cache. I was referring to a light weight instance 
validity  test first, and then fall back to the segment instance test.  But, as 
you indicate, this one might be totally useless in a frequently modifying 
workspace. 

I'll try to implement some of these options sunday, and try to capture some 
performance figures. WDYT?


> UUIDDocId cache does not work properly because of weakReferences in 
> combination with new instance for combined indexreader 
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-1213
>                 URL: https://issues.apache.org/jira/browse/JCR-1213
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: query
>    Affects Versions: 1.3.3
>            Reporter: Ard Schrijvers
>             Fix For: 1.4
>
>
> Queries that use ChildAxisQuery or DescendantSelfAxisQuery make use of 
> getParent() functions to know wether the parents are correct and if the 
> result is allowed. The getParent() is called recursively for every hit, and 
> can become very expensive. Hence, in DocId.UUIDDocId, the parents are cached. 
> Currently,  docId.UUIDDocId's are cached by having a WeakRefence to the 
> CombinedIndexReader, but, this CombinedIndexReader is recreated all the time, 
> implying that a gc() is allowed to remove the 'expensive' cache.
> A much better solution is to not have a weakReference to the 
> CombinedIndexReader, but to a reference of each indexreader segment. This 
> means, that in getParent(int n) in SearchIndex the return 
> return id.getDocumentNumber(this) needs to be replaced by return 
> id.getDocumentNumber(subReaders[i]); and something similar in 
> CachingMultiReader. 
> That is all. Obviously, when a node/property is added/removed/changed, some 
> parts of the cached DocId.UUIDDocId will be invalid, but mainly small indexes 
> are updated frequently, which obviously are less expensive to recompute.

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

Reply via email to