SPI: local vs remote checking

[Julian Reschke <ju...@gmx.de>]

Hi,

I am using jcr2spi on top of a custom SPI implementation, and was trying 
to come up with test cases that check the locking semantics (because I 
know they weren't complete in my implementation).

After some testing I realized that JCR2SPI already does lock checking 
locally (see ItemStateValidator.isWritable()). This indeed works (in 
that the client sees a compliant JCR impl), but this still left me 
wondering whether this really is a good approach:

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

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

Maybe this is something that the transient layer only does optionally, 
based on what the SPI server recommends?

(There are other local checks (such as access and check-out state) here 
as well, but maybe we can focus on one aspect at a time...)

Best regards, Julian

Re: SPI: local vs remote checking

[Angela Schreiber <an...@day.com>]

> Is the SPI implementation supposed to ever throw a LockException, 

definitely

> or can it rely on the transient layer doing lock checks upfront? 

that's a rhetoric question, right?
the spi impl must not rely on the client to behave properly.
but the client may cover some obvious cases (e.g. if the client
is always updated).

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

as i said before: my intention is, that the client not 'always'
check but does, when it can assume, that a lock is present
(as explained in my last mail)...

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

i guess, noone would oppose ;)
that argument is general enough that everybody agrees.

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

auch gut.
feel free to propose concrete changes, that would fit your
needs. then we have something real do to argue about.

regards
angela

Re: SPI: local vs remote checking

[Julian Reschke <ju...@gmx.de>]

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

Re: SPI: local vs remote checking

[Angela Schreiber <an...@day.com>]

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