Workspace Data Container

Workspace Data Container

Each Workspace of JCR has its own persistent storage to hold workspace's items data. eXo Content Repository can be configured so that it can use one or more workspaces that are logical units of the repository content. Physical data storage mechanism is configured using mandatory element container. The type of container is described in the attribute class = fully qualified name of org.exoplatform.services.jcr.storage.WorkspaceDataContainer subclass like

<container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
  <properties>
    <property name="source-name" value="jdbcjcr1"/>
    <property name="dialect" value="hsqldb"/>
    <property name="multi-db" value="true"/>
    <property name="max-buffer-size" value="200K"/>
    <property name="swap-directory" value="target/temp/swap/ws"/>
  </properties>

Properties are Container specific parameters.

Where :

source-name - JDBC data source name, registered in JDNI by InitialContextInitializer. (sourceName prior v.1.9)

dialect - database dialect, one of "hsqldb", "mysql", "mysql-utf8", "pgsql", "oracle", "oracle-oci", "mssql", "sybase", "derby", "db2", "db2v8"

multi-db - enable multi-database container with this parameter (if "true").

max-buffer-size - a threshold in bytes, if a value size is greater then it will be spooled to a temporary file.

swap-directory - a location where the value will be spooled if no value storage is configured but a max-buffer-size is exceeded.

eXo JCR has an RDB (JDBC) based, production ready Workspace Data Container.

Workspace Data Container MAY support external storages for javax.jcr.Value (which can be the case for BLOB values for example) using the optional element value-storages. Data Container will try to read or write Value using underlying value storage plugin if the filter criteria (see below) match the current property.

<value-storages>
  <value-storage id="Storage #1" class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
    <properties>
      <property name="path" value="data/values"/>
    </properties>
    <filters>
     <filter property-type="Binary" min-value-size="1M"/><!-- Values large of 1Mbyte -->
    </filters>
.........
</value-storages>

Where value-storage is the subclass of org.exoplatform.services.jcr.storage.value.ValueStoragePlugin and

properties are optional Plugin specific parameters.

filters Each file value storage can have the filter(s) for incoming values.

A filter can match values by property type (property-type), property name (property-name), ancestor path (ancestor-path) and/or the size of values stored (min-value-size, e.g. 1M, 4.2G, 100 (bytes)).

In a code sample we use a filter with property-type and min-value-size only. I.e. storage for binary values with the size greater than 1Mbyte.

It's recommended to store properties with large values in a file value storage only.