jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Thu, 14 Feb 2008 17:53:01 GMT

I've been playing around with SPI-side caching of the result of 
getChildInfos() (keeping the associated NodeInfos in memory), and I can 
gain something like a factor of 8 for SPI access.

So getting back to Marcel's ideas:

Why don't we change things so that ItemInfo *extends* ChildInfo, so that 
SPI implementations can return NodeInfos as well? JCR2SPI could then use 
that to update its internal cache, avoiding to refetch the NodeInfos.


BR, Julian

View raw message