Before going through Workspace Data Container, you need to learn about the following concepts:
Workspace Data Container (container) serves Repository Workspace
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 (
implementation). Each connection represents a transaction on the
storage. Storage Connection (connection) should be an implementation of
Container acts as a factory of a new storage connection. Usually, this method is designed to be synchronized to avoid possible concurrent issues.
WorkspaceStorageConnection openConnection() throws RepositoryException;
connections can be potentially a bit faster in some cases.
WorkspaceStorageConnection openConnection(boolean readOnly) throws RepositoryException;
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.
Storage connection might also be reused. This means that the reuse of physical resource (for example, JDBC Connection) is allocated by one connection in another. This feature is used in a data manager for saving ordinary and system changes on the system Workspace. But the reuse is an optional feature and it can work, otherwise a new connection will open.
WorkspaceStorageConnection reuseConnection(WorkspaceStorageConnection original) throws RepositoryException;
When you check Same-Name Siblings (SNS) existence, JCR Core can use a new connection or not. This is defined via Workspace Data Container configuration and retrieved by using a special method.
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.
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
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
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).
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 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.