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: local vs remote checking
Date Fri, 23 Feb 2007 13:46:40 GMT
Angela Schreiber schrieb:
> hi julian
>> (1) First of all, it leaves the question open whether an SPI 
>> implementation actually needs to implement the locking semantics, or 
>> whether *persisting* and *returning* the lock information is 
>> sufficient.  In any case, this should be documented well.
> ? what do you mean?

Is the SPI implementation supposed to ever throw a LockException, or can 
it rely on the transient layer doing lock checks upfront? (I personally 
would want the SPI implementation do it).

>> (2) It seems to me that we're doing more roundtrips to the server than 
>> necessary. This is likely to cause performance degradation for write 
>> operations to remote servers.
> that might be... on the other hand i think the jcr2spi
> implementation should determine a possible problem such
> as a lock, as soon as possible.
> therefore, i wanted to force a different behaviour between
> the API methods such as Node.isLocked(), that must always
> return the correct result, and the check-methods, which the
> specification defines to be optional: transient modifications
> may lead to LockException but they may only fail upon save.
> So: if during the check no lock is determined, that doesn't
> mean, that no lock is present. if however the hierarchy
> contains an entry, that indicates a lock, i think its worth
> informing the API user before the save call.
> If you have compelling reasons not to do so, we may change
> that. Suggestions are welcome.

Two reasons are:

(1) If the transient layer always attempts to check for locks, the SPI 
code that actually implements lock checks may never be used (code coverage).

(2) Performance - we need to balance between "fail early" and "reduce 
roundtrips between JCR and SPI layer".

>> Maybe this is something that the transient layer only does optionally, 
>> based on what the SPI server recommends?
> ... rather based on the 'CacheBehaviour' in case the jcr2spi
> is always up to date, since it gets always updated by
> observation, then it might not be necessary to ask the server.

I wouldn't want the transient layer to check for locks, even if 
CacheBehaviour is INVALIDATE.

Best regards, Julian

View raw message