Julian Reschke wrote:
Marcel Reutegger wrote:
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.
see JCR-1011. we just have to commit the patch.
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).
that's why I don't even want to get into this business. but if an implementation
wants to cache something it is responsible for maintaining it.
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.
it is a fundamental requirement that the SPI implementation provides the most
up-to-date item that is available. the refresh semantic is only relevant in the
context of jcr2spi but not the SPI itself.
[...] or just discard the SessionInfo and get a fresh one.
that's contrary to how the SessionInfo is designed. It is meant to be the result
of a successful authentication. If it holds state information that is relevant
to the server (e.g. a cache, a JCR session, JDBC connection, ...) it is the
responsibility of the implementation to maintain it. An SPI client does not need
nor use that information directly.
Again any call using a SessionInfo should return the most up-to-date item(s)
that are requested.
> 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 [...]
That's IMO a more relevant use case that we should consider rather than caching.
regards
marcel
