jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Fri, 08 Feb 2008 13:35:26 GMT
Julian Reschke wrote:
> Marcel Reutegger wrote:
>> David Rauschenbach wrote:
>>> My main problem with SPI is that if I return depth=1 results from
>>> getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up 
>>> subsequently
>>> calling getChildInfos anyway, to find out what ALL the children are,
>>> regardless of the fact that I just returned what all the children are 
>>> in my
>>> GetItemInfos response.
>> this is because jackrabbit-jcr2spi did not have a cache. angela 
>> recently committed the changes discussed in JCR-1011. this introduces 
>> a cache and should avoid the calls for the children if they were 
>> delivered in a previous call.
> How would JCR2SPI that *all* children have been returned?

good question! I don't know. I'm not that familiar anymore with the jcr2spi 
code. I remember a discussion with angela about a flag, which indicates that 
child node entries are complete. But I guess we never implemented this.

I think your question reveals a design flaw in the batch read method 
RepositoryService.getItemInfos(). And it's not just about knowing all children, 
it's also about the order of nodes. Even if we are sure we got all children we 
still have to call getChildInfos() in case the parent supports orderable child 
nodes. Angela, please correct me, if I'm way off here...

Hmmm, does that mean a batch read should also be allowed to return ChildInfo, 
with the restriction that it must be complete, when sent?

> And how should 
> the SPI implementation know that somebody *wants* to retrieve all children?

I'm not sure I understand your question, because there is 
RepositoryService.getChildInfos(). Do you mean something else?


View raw message