jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "Clustering" by ThomasMueller
Date Wed, 25 Mar 2009 10:44:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The following page has been changed by ThomasMueller:

The comment on the change is:
sync delay

  Every change made by one cluster node is reported in a journal, which can be either file
based or written to some database.
- == Prerequisites ==
+ == Requirements ==
  In order to use clustering, the following prerequisites must be met:
@@ -13, +13 @@

   * A journal type must be chosen, either based on files or stored in a database
   * The persistence managers must store their data in the same, globally accessible location
- Let's look at these steps in more detail:
- === Unique cluster node ID ===
+ === Unique Cluster Node ID ===
  Every cluster node needs a unique ID that will help identify the author of some change.
This ID can be either specified in the cluster configuration as '''id''' attribute or as value
of the system property '''org.apache.jackrabbit.core.cluster.node_id'''. When copying repository
configurations, do not forget to adapt the cluster node IDs if they are hardcoded. See below
for some sample cluster configurations. A cluster id can be freely defined, the only requirement
is that it has to be different on each cluster node.
+ === Sync Delay ===
+ By default, cluster nodes read the journal and update their state every 5 seconds (5000
milliseconds). To use a different value, set the attribute ''syncDelay'' in the cluster configuration.
- === Journal type ===
+ === Journal Type ===
  The cluster nodes store information identifying items they modified in a journal. This journal
must again be globally available to all nodes in the cluster. This can be either a folder
in the file system or a database running standalone.
- ==== File journal ====
+ ==== File Journal ====
  The file journal is configured through the following properties:
   * '''revision''': location of the cluster node's revision file
   * '''directory''': location of the journal folder
- ==== Database journal ====
+ ==== Database Journal ====
  The database journal is configured through the following properties:
@@ -40, +42 @@

   * '''user''': user name
   * '''password''': password
- == Sample cluster configuration ==
+ == Sample Cluster Configuration ==
  This section contains some sample cluster configurations. First, using a file based journal
implementation, where the journal files are created in a share exported by NFS:
@@ -53, +55 @@

- In the next configuration, the journal is stored in an Oracle database:
+ In the next configuration, the journal is stored in an Oracle database, using a sync delay
of 2 seconds (2000 milliseconds):
- <Cluster id="node1">
+ <Cluster id="node1" syncDelay="2000">
    <Journal class="org.apache.jackrabbit.core.journal.OracleDatabaseJournal">
      <param name="revision" value="${rep.home}/revision.log" />
      <param name="driver" value="oracle.jdbc.driver.OracleDriver" />
@@ -69, +71 @@

  '''Note''': the journal implementation classes have been refactored in Jackrabbit 1.3. In
earlier versions, journal implementations resided in the package ''org.apache.jackrabbit.core.cluster''.
- === Persistence manager configuration ===
+ === Persistence Manager Configuration ===
  For performance reasons, only information identifying the modified items is stored in the
journal. This implies, that all cluster nodes must have access to the items' actual content.
The persistence manager needs to be transactional, and need to support concurrent access from
multiple processes. When using Jackrabbit, one option is to use a database persistence manager,
and use a database that does support concurrent access. The file system based persistence
managers in Jackrabbit are not transactional and don't support concurrent access; Apache Derby
doesn't support concurrent access in the embedded mode. The following sample shows a workspace's
persistence manager configuration using an Oracle database:

View raw message