On 2016-10-04 10:48, Michael Dürig wrote:
On 3.10.16 4:33 , Robert Munteanu wrote:
* Where are the limitation and how are we going to deal with them?
> Specifically: how do you deal with atomicity when multiple node
> stores
> are mounted? Similarly, how do you guarantee global constraints
> (like
> uniqueness).
We explicitly set write multiplexing as a non-goal. This works for now
as a side-effect - it was too easy to implement :-)
So we will have at most ( usually exactly ) one store which is write-
enabled, and all other stores will be read-only. In the scenarios
above, /libs and /apps will be read-only.
At a JCR level we will make sure that the mounted repositories, except
the global one, will have no 'troublesome' nodes: no versioning, no
referenceable nodes, etc.
So we need to put some safeguards into place ensuring those
prerequisites actually hold. If this cannot be done we at least need
to clearly document them. What I want to avoid here is suddenly
finding ourselves in the position where we are forced to support the
"full" use case. Let's add the uses cases and constraints identified
in this thread to the issue (or dedicated issues) so we don't forget.
Created a sub-task for this
OAK-4891 - Mount-time sanity checks for mounted NodeStore instances
https://issues.apache.org/jira/browse/OAK-4891
> * How is (un)mounting handled? How do you ensure the node store
> satisfy
> all higher level constraints?
Mounting is configured via OSGi and expected to not change at runtime.
Doing this dynamically is a non-goal.
As for the other high-level constraints, a read-only mount with
limited
JCR capabilities in terms of versioning, locking, etc should not pose
any issues. Can you maybe add some specific scenarios that you think
can be problematic?
This boils down to the same concerns as above: how do we make
sufficiently sure that only such node stores are mounted which do not
make use of these troublesome features? What happens if this is
violated? (How) can we fail fast? I could imagine cases where this
goes unnoticed for a long time but then suddenly starts failing in way
very strange and hard to diagnose ways. For example: if accidentally a
node store is mounted that violates the uniqueness constraint (e.g.
UUID index). Can we detect this at mount time? What happens if not?
I think we should both ensure that when a mount is exported all
troublesome
node structures are cleaned. Also, we should detect and fail fast at
mount
time. I prefer a slightly slower mount time to runtime errors :-)
Thanks,
Robert
