hi jukka IMO the approach in the namespaceregistry is something different: in that case you have a different write-root that needs to make sure that the root (and the editing session) gets updated once the changes are persisted.
but in this case as michael explained the setup is that one session should be informed about modifications made by another session. this works for all operations that are 'attached' to the SessionDelegate but the refresh doesn't work for those classes that are just associated with the Root (such as e.g. the UserManager which btw. makes transient modifications on the root associated with editing session. the read-write trick doesn't help here). btw: it's one of the fundamental design decisions for the oak security code to build the implentations on top of the OAK API. this contrasts to the Jackrabbit setup which lead to a lot of hacks and at the end didn't work very well. so, what we would need is a refresh on the Root instead of just refreshing upon session access. i just discussed this with Michael and we both fear that this will open a huge can of worms... what we are basically trying to do is to changing one of the fundamental concepts of OAK (refresh only occurs if manually triggered), which IMHO needs a careful analysis of the consequences. let's discuss that in the call this afternoon. angela On 8/6/13 10:41 AM, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig <[email protected]> wrote: >> We might have similar issues with other entities tied to a session like >> PrincipalManager, VersionManager, ... Basically all (indirect) callers >>of >> SessionDelegate#getRoot() are suspect... and that's quite a list. > >We sorted out a good pattern for doing stuff like this already with >the namespace registry. Basically: > >a) When making transient changes or reading information that can come >from an earlier repository snapshot, use sessionDelegate.getRoot() so >that you see the exact same state as the rest of the session. > >b) When persisting changes directly to the repository or reading from >the latest repository state without interference from transient >changes, use sessionDelegate.getContentSession().getLatestRoot() and >follow up with a session.refresh(true) to force the rest of the >session to keep up. > >The abstract method pattern in ReadWriteNamespaceRegistry (or >something similar) can be used to avoid a direct oak-jcr / >SessionDelegate dependency. > >That pattern should cover the needs of the UserManager and other >places without the need to manage the states of multiple independent >Root instances. > >BR, > >Jukka Zitting
