jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: SPI: local vs remote checking
Date Fri, 23 Feb 2007 12:20:28 GMT
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?

> (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.

> 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.


View raw message