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
