3.2.2. Workspace data container

3.2.2.1. Requirements
3.2.2.2. Value storages API
3.2.2.3. How to implement workspace data container

Before going through Workspace Data Container, you need to learn about the following concepts:

Container and connection

Workspace Data Container (container) serves Repository Workspace persistent storage. WorkspacePersistentDataManager (data manager) uses container to perform CRUD operation on the persistent storage. Accessing the storage in the data manager is implemented via the storage connection obtained from the container (WorkspaceDataContainer interface implementation). Each connection represents a transaction on the storage. Storage Connection (connection) should be an implementation of WorkspaceStorageConnection.

WorkspaceStorageConnection openConnection() throws RepositoryException;
WorkspaceStorageConnection openConnection(boolean readOnly) throws RepositoryException;

*EXPERIMENTAL*

Read-only WorkspaceStorageConnection is an experimental feature and not currently handled in JCR. Actually, such connections did not prove their performance, so JCR Core does not use them.

WorkspaceStorageConnection reuseConnection(WorkspaceStorageConnection original) throws RepositoryException;
boolean isCheckSNSNewConnection();

Container initialization is only based on a configuration. After the container has been created, it is not possible to change parameters. Configuration consists of implementation class and set of properties and Value Storages configuration.

Value storages

Container provides an optional special mechanism for Value storing. It is possible to configure external Value Storages via container configuration (available only via configuration). Value Storage works as a fully independent pluggable storage. All required parameters of the storage obtains from its configuration. Some storages are possible for one container. Configuration describes such parameters as the ValueStoragePluginimplementation class, set of implementation specific properties and filters. The filters declares criteria for Value matching to the storage. Only matched Property Values will be stored. So, in common case, the storage might contains only the part of the Workspace content. Value Storages are very useful for BLOB storing, for example, storing on the File System instead of a database.

Container obtains Values Storages from the ValueStoragePluginProvider component. Provider acts as a factory of Value channels (ValueIOChannel). Channel provides all CRUD operation for Value Storage respecting the transaction manner of work (how it can be possible due to implementation specifics of the storages).

Lifecycle

Container is used for read and write operations by data manager. Read operations (getters) use connection once and finally close it. The write operations perform in the commit method as a sequence of creating/ updating calls and the final commit (or rollback on error). Write uses one connection (or two - another for system workspace) per commit call. One connection guaranties transaction support for the write operations. Commit or rollback should free/clean all resources consumed by the container (connection).

Value storage lifecycle

Value storage is used from the container inside. Reads are related to a container reads. Writes are commit-related. Container (connection) implementation should use transaction capabilities of the storages in the same way as for other operations.

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus