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 Thu, 07 Feb 2008 08:11:08 GMT
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.

> 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.


View raw message