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
