How Replication Works

Replication in Bloomreach Content uses a push-based model. When changes occur on the source repository, they are packaged and sent to one or more target repositories. Monitoring for changes and sending replication packages are separate, asynchronous processes. If you configure multiple replication targets (supported in brXM 15.1.0 and later), each target receives packages independently.

Change Monitoring

Replication monitors repository changes by periodically scanning the repository journal for updates. Even in non-clustered CMS deployments, you must configure a repository journal to enable replication.

The replication process reads JCR events from the repository journal. These events may occur within or outside a unit of replication. A unit of replication is a set of nodes sent together to the target as a single serialized XML file. For example, a unit of replication may be a document variant and all its subnodes.

Replication ignores events on nodes outside the replication scope. Only events within defined units of replication are processed.

When a change is detected within a unit of replication, it is recorded in a change log. Each change log contains all units of replication modified during a single session save operation. This approach ensures consistency: as long as the application saves consistent changes within a session, replication will maintain that consistency.

If multiple change logs are queued, new change logs may overlap with earlier ones. For example, a node changed in an earlier operation may be changed again in a later operation. To maintain consistency, replication processes both changes together.

Sending Replication Packages

While the change monitor detects changes and queues change logs, a parallel process consumes these logs to create and send replication packages to the target. Each package is a ZIP file containing XML representations of the units of replication. The XML format is similar to system view XML with additional enhancements.

If concurrent changes affect the same replication scope while a package is being created, the process abandons the current package and retries with the next pending package. This prevents inconsistent replication states.

Importing Replication Packages

The source repository sends the replication package to the target repository using REST. The target unpacks the package and imports the serialized XML units of replication. Import occurs synchronously, allowing the target to report errors to the source in the REST response.

Some errors may trigger automated corrective actions on the source. For example, if import fails due to a missing ancestor node, the source initiates a partial synchronization of the subtree rooted at the missing ancestor.