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, 07 Feb 2008 11:12:52 GMT
Marcel Reutegger wrote:
> Julian Reschke wrote:
>> The store the SPI implementation talks to internally may be on a 
>> separate machine, so verifying that something is up-to-date (for read 
>> access) would actually defy the caching in the first place, wouldn't it?
> IMO an SPI implementation was never meant to cache anything. it is meant 
> to be as stateless as possible and translate SPI calls into calls on the 
> back-end. if an implementation reads more than it was asked for it may 
> pass it to the client of the SPI and hope it will be cached there.

That would be good, but right now SPI doesn't support it everywhere 
where it would be useful (and, afaik, JCR2SPI doesn't take advantage of it).

Example - obtaining a directory listing: SPI2JCR currently gets the 
NodeInfo for the collection, then gets the ChildInfo iterator, then for 
each NodeId of a child fetches that child's NodeInfo.

For a collection of N members, this translates to N additional 
roundtrips to the store (with WebDAV, PROPFINDs on each child resource, 
although a single PROPFIND with Depth 1 would have been sufficient).

It's not clear to me how it would be able to avoid this with the current 
SPI interfaces while disallowing SPI to cache.

>> Or do you expect SPI implementations to keep cached information 
>> up-to-date by some kind of observation mechanism?
> yes, if there is a cache present the implementation should maintain the 
> cache on its own without additional information from an SPI client.

I have the feeling that we're optimizing for the wrong use case here.

If we can't make *read* access efficient enough, we're in trouble. And I 
really don't want to require every SPI implementation to subscribe to 
events from the underlying store, in particular if it's remote (think HTTP).

JCR clients today can not rely on fresh session information unless they 
do a refresh(), and it's unclear to me why we would require that from an 
SPI implementation.

If the JCR client does call "refresh()", we really should pass that 
information to SPI, either by a new method (which could be more 
elaborate than just refresh() as mentioned by Angela), or just discard 
the SessionInfo and get a fresh one.

BR, Julian

View raw message