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
