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 the container mandatory element. The type of container is described in the class attribute = the fully qualified name of the org.exoplatform.services.jcr.storage.WorkspaceDataContainer subclass like:

<container class="org.exoplatform.services.jcr.impl.storage.jdbc.optimisation.CQJDBCWorkspaceDataContainer">
    <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"/>
    <property name="lazy-node-iterator-page-size" value="50"/>
    <property name="acl-bloomfilter-false-positive-probability" value="0.1d"/>
    <property name="acl-bloomfilter-elements-number" value="1000000"/>
    <property name="check-sns-new-connection" value="false"/>
    <property name="batch-size" value="1000"/>

Specific parameters of Workspace Data Container


Bloom filters are not supported by all the cache implementations so far only the implementation for infinispan supports it. They are used to avoid read nodes that definitely do not have ACL. acl-bloomfilter-false-positive-probability and acl-bloomfilter-elements-number are used to configure such filters. You can read here for more information about Bloom filters.

Specific parameters of JDBC Workspace Data Container

eXo JCR has an RDB (JDBC) based production ready Workspace Data Container which has the following specific parameters:

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

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


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

Database's dialects

PostgreSQL/PostgrePlus database

PostgreSQL/PostgrePlus's dialect is set automatically. The dialect depends on the version of database. If you change default value of standard_conforming_strings parameter, you must configure one of the following dialects manually:

DB2 database

As well as PostgreSQL, DB2's dialect is set automatically, depending on the version of database. If you change the default value of the DB2_COMPATIBILITY_VECTOR parameter, you must configure one of the following dialects manually:

MySQL database


Since MySQL NDB engine does not support foreign keys, which may lead to improper item removal and as consequence to InvalidItemStateException. In this case, you will need to use consistency checker tool.

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