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
- SPI: local vs remote checking Julian Reschke
-