Shared
ItemStateManager (SISM). Caches objects returned from a
PersistenceManager. Objects returned by this item state manager are shared among all sessions.
A shared item state manager operates on a
PersistenceManager (PM) that is used to load and store the item states. Additionally, a SISM can have
VirtualItemStateProviders (VISP) that are used to provide additional, non-persistent, read-only states. Examples of VISP are the content representation of the NodeTypes (/jcr:system/jcr:nodeTypes) and the version store (/jcr:system/jcr:versionStore). those 2 VISP are added to the SISM during initialization of a workspace. i.e. they are 'mounted' to all workspaces. we assume, that VISP cannot be added dynamically, neither during runtime nor by configuration.
The states from the VISP are read-only. by the exception for node references. remember that the referrers are stored in a {@link NodeReferences} state,having the ID of the target state.
there are 5 types of referential relations to be distinguished:
- normal --> normal (references from 'normal' states to 'normal' states) this is the normal case and will be handled by the SISM.
- normal --> virtual (references from 'normal' states to 'virtual' states) those references should be handled by the VISP rather by the SISM.
- virtual --> normal (references from 'virtual' states to 'normal' states) such references are not supported. eg. references of versioned nodes do not impose any constraints on the referenced nodes.
- virtual --> virtual (references from 'virtual' states to 'virtual' states of the same VISP). intra-virtual references are handled by the item state manager of the VISP.
- virtual --> virtual' (references from 'virtual' states to 'virtual' states of different VISP). those do currently not occur and are therefore not supported.
if VISP are not dynamic, there is not risk that NV-type references can dangle (since a VISP cannot be 'unmounted', leaving eventual references dangling). although multi-workspace-referrers are not explicitly supported, the architecture of
NodeReferences support multiple referrers with the same PropertyId. So the number of references can be tracked (an example of multi-workspace-referrers is a version referenced by the jcr:baseVersion of several (corresponding) nodes in multiple workspaces).
As mentioned, VN-type references should not impose any constraints on the referrers (e.g. a normal node referenced by a versioned reference property). In case of the version store, the VN-type references are not stored at all, but reinforced as NN-type references in the normal states in case of a checkout operation.
VV-type references should be handled by the respective VISP. they look as NN-type references in the scope if the VISP anyway...so no special treatment should be necessary.
VV'-type references are currently not possible, since the version store and virtual node type representation don't allow such references.