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 17:02:30 GMT
David Rauschenbach wrote:
> also worth mentioning is why a requested-depth argument is missing from
> getItemInfos. It's just a little strange for the server to choose what to do,
> or to have a pre-configured nodetype-specific batch strategy configured
> there, when the client is where it's at, where it's known what's to be
> requested.

our primary SPI client that we have in mind is jcr2spi. here we are in the same 
tight spot. jcr2spi does not know in advance what properties a client will 
request after it got a node. even if we had the ability in the SPI to pass a 
hint, jcr2spi cannot make use of it in a reasonable way.

for jcr2spi there are only two patterns it can distinguish. a JCR client gets a 
named item (getNode/Property()) or an iterator over items 
(getNodes/Properties()). At least the latter should not result in individual 
calls for each item.


View raw message