Question

I am using modeshape 3.6.0.Final with JBOSS 6 EAP.

According to https://github.com/ModeShape/modeshape/blob/master/deploy/jbossas/modeshape-jbossas-subsystem/src/main/resources/schema/modeshape_1_0.xsd the previous element

cache-index-storage

for configuring the cache amongst others via the JDBC have been removed.

I found some all configurations and that is exactly what i would like to achieve:

<cache-index-storage 
cache-container-jndi-name="index_cache_container" 
    lock-cache-name="index_locks" 
    data-cache-name="index_data"
    metadata-cache-name="index_metadata"/>

and the cache container

            <!-- index storage, metadata and locks -->
       <cache-container name="index_cache_container" default-cache="index_data">
            <local-cache name="index_locks">
                <transaction mode="NON_XA"/>
                <string-keyed-jdbc-store datasource="java:jboss/datasources/MySqlDS" passivation="false" purge="false">
                    <property name="databaseType">MYSQL</property>
                    <property name="createTableOnStart">true</property>
                    <string-keyed-table prefix="stringbased">
                        <id-column name="id_column" type="VARCHAR(255)"/>
                        <data-column name="data_column" type="BLOB"/>
                        <timestamp-column name="timestamp_column" type="BIGINT"/>
                    </string-keyed-table>
                </string-keyed-jdbc-store>
            </local-cache>
            <local-cache name="index_data" batching="true">
                <transaction mode="NON_XA"/>
                <string-keyed-jdbc-store datasource="java:jboss/datasources/MySqlDS" passivation="false" purge="false">
                    <property name="databaseType">MYSQL</property>
                    <property name="createTableOnStart">true</property>
                    <string-keyed-table prefix="stringbased">
                        <id-column name="id_column" type="VARCHAR(255)"/>
                        <data-column name="data_column" type="BLOB"/>
                        <timestamp-column name="timestamp_column" type="BIGINT"/>
                    </string-keyed-table>
                </string-keyed-jdbc-store>
            </local-cache>
            <local-cache name="index_metadata">
                <transaction mode="NON_XA"/>
                <string-keyed-jdbc-store datasource="java:jboss/datasources/MySqlDS" passivation="false" purge="false">
                    <property name="databaseType">MYSQL</property>
                    <property name="createTableOnStart">true</property>
                    <string-keyed-table prefix="stringbased">
                        <id-column name="id_column" type="VARCHAR(255)"/>
                        <data-column name="data_column" type="BLOB"/>
                        <timestamp-column name="timestamp_column" type="BIGINT"/>
                    </string-keyed-table>
                </string-keyed-jdbc-store>
            </local-cache>
        </cache-container>

Can anyone give me an hint on how to configure the cache for indexes for modeshape 3.6.0.Final such that they are stored in a database?

Thanks in advance for your help?

Was it helpful?

Solution

The ModeShape community removed support for storing Lucene indexes inside a database because it performed horribly, especially for writes since a concurrent changes to content on different processes each compete for writes to the database. Even in a non-clustered topology, storing indexes in a database is simply not recommended due to performance.

It is much better to have each process in the cluster maintain its own complete copy of the index. Yes, this does add work to each write (since the write has to be done on each process), but it significantly improves query performance and eliminates the potential for cluster-wide write conflicts, thus increasing the update throughput of the system.

Of course it is still possible to store indexes in Infinispan. ModeShape kept this option because Infinispan can be configured in ways that don't use a shared storage (essentially making each process have independent indexes), and in these configurations there is no cluster-wide index write conflict. But storing the indexes in a shared database will again there is likely to be cluster-wide index write conflicts.

You can try it out if you want, and if you do make sure that each of the three caches are stored in a separate database table (using a unique value for the "prefix" attribute).

However, I would strongly encourage you to not store your indexes in a relational database or another location shared by multiple processes in the cluster.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top