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