eXo Repository Service is a JSR 170-based standard service and is a registered IoC (Inversion Of Control) component that can be deployed in some eXo Containers (see Repository service configuration for more details). The relationships between components are shown in the picture below:
Repository Service: Contain information about repositories. eXo JCR is able to manage many Repositories.
Repository: Implementation of
javax.jcr.Repository. It holds references to one or more
Workspace: Container of a single rooted tree of
Items. (Note that here it is not exactly the same as
javax.jcr.Workspace as it is not a Session object). See Workspace for the workspace configurations.
The JCR application usecase typically includes two initial steps:
Obtaining Repository object by getting Repository Service from the current eXo Container (eXo "native" way) or via JNDI lookup if eXo repository is bound to the naming context using (see Repository configuration for more details).
javax.jcr.Session object that calls
The following diagram explains which components of eXo JCR implementation are used in a data flow to perform operations specified in JCR API.
The Workspace Data Model can be split into 4 levels by the data isolation and value from the JCR model point of view.
eXo JCR core: Implements the JCR API interfaces, such as Item, Node, Property. It contains JCR "logical" view on stored data.
Session Level: Isolates the transient data viewable inside one JCR Session and interacts with API level using eXo JCR internal API.
Session Data Manager: Maintains the transient session data. With data access/ modification/ validation logic, it contains Modified Items Storage to hold the data changed between subsequent save() calling and Session Items Cache.
Transaction Data Manager: Maintains the session data between save() and transaction commit/ rollback if the current session is part of a transaction.
Workspace Level: Operates for the particular workspace shared data. It contains objects of each Workspace.
Workspace Storage Data Manager: Maintains the workspace data, including final validation, events firing, and caching.
Workspace Data Container: Implements the physical data storage. It allows different types of backend (such as RDB, FS files) to be used as a storage for JCR data. With the main Data Container, other storages for the persisted Property Values can be configured and used.
Indexer: Maintains the workspace data indexing for further queries.
Storage Level: Persistent storages for:
Indexes (Apache Lucene).
Values (for example, for BLOBs) if being different from the main Data Container.