jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Wed, 06 Feb 2008 15:47:39 GMT
Angela Schreiber wrote:
> hi julian
> 
>> this issue made me think that we may be missing something in the SPI...
>>
>> So, is an SPI implementation allowed to internally cache things (for 
>> instance, with the SessionInfo implementation)? I would assume so (but 
>> maybe I'm wrong).
> 
>> If it is allowed to do that, shouldn't a Session.refresh() call be 
>> reflected in some SPI call, so that the SPI implementation can 
>> invalidate caches as well?
> 
> that sounds strange to me. if the SPI does some kind of caching
> it should rather communicate with the implementation below in
> order to update/refresh the cache.

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?

Or do you expect SPI implementations to keep cached information 
up-to-date by some kind of observation mechanism?

> ...

BR, Julian

Mime
View raw message