Share delivery schedules between runtimes

Semarchy xDI Runtime can run as a cluster of multiple runtimes that share delivery schedules. The runtimes implement the Quartz scheduling library, which manages schedule clustering.

This implementation requires multiple active runtimes, as well as a single database all runtimes can access. If the runtimes are on separate machines, you must also keep the machine clocks synchronized.

Create the database tables

If you have not yet done so, create a database to store runtime scheduling information. Then follow the scheduler configuration instructions to create the tables needed by the schedulers.

Configure schedule clustering

For each runtime, open its engineParameters.xml configuration file. Find the <scheduler> node, and edit the nested parameters as follows:

Main properties

Set the org.quartz.scheduler.instanceName parameter to a unique name, and set org.quartz.scheduler.instanceId to AUTO.

<!-- Main properties -->
<parameter name="org.quartz.scheduler.instanceName" value="MyClusteredScheduler"/>
<parameter name="org.quartz.scheduler.instanceId" value="AUTO"/>

Configure job stores

Set org.quartz.jobStore.isClustered to true.

If you want to create a separate datasource for your database connection, set the org.quartz.jobStore.dataSource parameter to a different name. Otherwise, you can leave it at its default value, internal.

<!-- Configure Jobstore -->
<parameter name="org.quartz.jobStore.dataSource" value="xdiRuntimeCluster"/>
<parameter name="org.quartz.jobStore.isClustered" value="true"/>

If you are using Microsoft SQL server to store your schedule, add the following parameters:

<parameter name="org.quartz.jobStore.selectWithLockSQL" value="SELECT * FROM {0}LOCKS UPDLOCK WHERE LOCK_NAME = ?"/>
<parameter name="org.quartz.jobStore.lockHandler.class" value="org.quartz.impl.jdbcjobstore.UpdateLockRowSemaphore"/>
<parameter name="org.quartz.jobStore.acquireTriggersWithinLock" value="true"/>

Configure datasources

Configure your chosen datasource by following the scheduler configuration instructions. Make sure the name of the parameter references the value of the org.quartz.jobStore.dataSource parameter.

For example, here is a sample Oracle configuration with the earlier xdiRuntimeCluster datasource name:

<!-- Configure Datasources -->
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.driver" value="oracle.jdbc.driver.OracleDriver"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.URL" value="jdbc:oracle:thin:@127.0.0.1:1521:xe"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.user" value="oracle-user"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.password" value="oracle-password"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.maxConnections" value="5"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.validationQuery" value="select 0 from dual"/>
<parameter name="org.quartz.dataSource.xdiRuntimeCluster.module" value="default"/>

Your actual settings should match your database configuration.

Copy the settings

Make sure the <scheduler> node has identical main and Jobstore settings across all files. The Datasource settings should also match, but modify the URL if it changes based on each runtime’s install location.

Finish

Create, modify, or remove a schedule to automatically share it between the runtimes. Each runtime that shares a configuration receives schedules created in the cluster, even if the runtime was unavailable when you created the schedule.