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 12:45:55 GMT
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

Mime
View raw message