jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rauschenbach <david.rauschenb...@synchronica.com>
Subject Re: JCR2SPI causes unnecessary getPropertyInfo to obtain primaryType
Date Mon, 17 Mar 2008 15:53:23 GMT
I am remoting SPI, so I have to care about this, and block unnecessary
invocations in my client. As it is, my client-side cache runs at around
95% cache hits! That's how many SPI calls I have to block and not
interpret literally, by answering them out of a cache of prior
getItemInfos responses.

Some of the short-cuts I take are domain-specific, because I know UUID's
are not going to get used. So I suppose a few things in my cache will
stick around, after JCR2SPI picks up the slack and does some of the
things that applies to everyone.

David



On Mon, 2008-03-17 at 16:41 +0100, Julian Reschke wrote:
> David Rauschenbach wrote:
> > I wanted to pass this finding along, just to get it out there.
> > 
> > After JCR2SPI submits a batch with a new node, it performs a getItemInfos, presumably
to refresh the node and see what server-side items might have been assigned. This ItemInfo
response, by definition, as a NodeInfo at element 0, containing the primaryType of the node.
> > 
> > If the target server, for whatever reason, opts to NOT include a PropertyInfo for
the jcr:primaryType of the added node, JCR2SPI asks for it by invoking getPropertyInfo. It
should not do so, because the primary type was returned in the NodeInfo.
> > 
> > In summary, this is more like a design strategy in JCR2SPI. Deteremining a primary
type should be done using the mandatory part of a getItemInfos response (the node info), instead
of using the optional part of a getItemInfos response, which could cause additional I/O for
no good reason.
> 
> +0.5.
> 
> I'm not too concerned about write performance (yet).
> 
> However, I also see calls to getPropertyInfo for 
> primarytype/mixintypes/uuid, when the JCR client just calls getProperties().
> 
> This really should be avoided; I'd even say that when JCR2SPI already 
> has the NodeInfo, getPropertyInfo should never be called for the 
> properties defined on nt:base, and optimally also not for jcr:uuid when 
> the NodeInfo can already provide it.
> 
> Is there a particular reason why JCR2SPI doesn't do that yet? It would 
> require some additional code building properties, but I think it would 
> be worth it.
> 
> BR, Julian

Mime
View raw message