eXo JCR Implementation

eXo JCR Implementation

Related Documents

• Access Control
• Configuration
• Export Import Implementation
• External Value Storages
• JDBC Data Container config
• Locking
• Multilanguage support
• Node types and Namespaces
• Repository and Workspace management
• Repository container life cycle
• Workspace Persistence Storage
• Workspace SimpleDB storage

How it works

eXo Repository Service is a standard eXo service and is a registered IoC component, i.e. can be deployed in some ExoContainer (see {{{configuration.html}Service configuration}} for details) Relationships between components are shown in the picture below:

• Exo Container some subclass of org.exoplatform.container.ExoContainer (usually org.exoplatform.container.StandaloneContainer or org.exoplatform.container.PortalContainer) that holds a reference to RepositoryService
• Repository Service contains 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(s)
• 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 per Session object)

• Obtaining Repository object by getting RepositoryService from current ExoContainer (eXo "native" way) or via JNDI lookup if eXo repository is bound to the naming context using (see {{{configuration.html}Service configuration}} for details)
• Creating javax.jcr.Session object that calls Repository.login(..)

Workspace Data Model

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 splitted into 4 levels by data isolation and value from the JCR model point of view.

• eXo JCR core implements JCR API intefaces 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. Along with data accessing/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. Along 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 (for BLOBs for ex) if different from main Data Container