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 data isolation and value from the JCR model point of view.
eXo JCR core implements JCR API interfaces, such as Item, Node, Property. It contains JCR "logical" view on stored data.
Session Level: isolates transient data viewable inside one JCR Session and interacts with API level using eXo JCR internal API.
Session Data Manager: maintains 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 session data between save() and transaction commit/ rollback if the current session is part of a transaction.
Workspace Level: operates for particular workspace shared data. It contains per-Workspace objects
Workspace Storage Data Manager: maintains workspace data, including final validation, events firing, caching.
Workspace Data Container: implements physical data storage. It allows different types of backend (like RDB, FS files, etc) to be used as a storage for JCR data. With the main Data Container, other storages for persisted Property Values can be configured and used.
Indexer: maintains workspace data indexing for further queries.
Storage Level: Persistent storages for:
JCR Data
Indexes (Apache Lucene)
Values (e.g., for BLOBs) if different from the main Data Container