Marcel Reutegger wrote:
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.
I think I understand batch read, and how JCR2SPI would use that. What I
don't see how it helps in this case.
An SPI implementation *could* return ItemInfos for all children when the
NodeInfo for a collection is fetched, but how would it know that anybody
wants to see the members?
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.
That's a broad statement.
JCR includes "refresh" for good reasons. Are you arguing that it's not
needed, and a JCR implementation is responsible for that as well?
I think that would be a fundamentally bad idea, because whether cache
information needs to be fresh depends on what the client does. There's
no way how the JCR or the SPI implementation would know.
If a client does a collection listing, asking for a limited set of
properties of the members (name, timestamps, mime type, length), it
really doesn't care much. However, the SPI implementation has no
knowledge about the context in which the information in the NodeInfo is
needed, and thus has no way to optimize the operation.
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.
Where does this requirement come from? Is it stated somewhere? Did you
ever try to compare performance between native Jackrabbit, and an SPI
based solution for operations like the one mentioned above?
[...] 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.
I didn't claim it does.
Again any call using a SessionInfo should return the most up-to-date
item(s) that are requested.
Requiring this sounds nice in theory, but I'm *very* skeptic that it
works in practice.
> 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.
I'm not sure how this is a different use case, but I really don't care
for the motivation.
At the end of the day, what we should do is *measure* the performance of
JCR2SPI compared to native implementations. I'll try to submit a few
tests soon.
BR, Julian
