The "Pairing Configuration" allows you to configure names for the hashing- and partner tables. All partner-servers which share the same database and the same table-names will be paired together. Using different table-names for different servers you can configure which servers should be in the same pairing-group. This way different pairing-groups can be stored in the same database.
The pairing mechanism ensures that if one partner-server fails, the other server(s) will seamlessly take over the processing of the paired workflows. This makes pairing both a kind of load-balancing and fail-over mechanism.
On a more technical level:
Each time a paired-workflow starts to run, it checks the hashing-table to find out if another partner-server is already processing a workflow with the same trigger-settings. If not, a hash-code is generated from the trigger-type (Hotfolder, FTP, Query), inserted in the hashing-table and the workflow starts to run. This hash-code is the actual "trick" to the pairing mechanism because it is based on the exact trigger-settings (hotfolder-path for Hotfolder-trigger, FTP-settings for FTP-trigger and Query-settings for Database-trigger). This means that if different servers are using the same settings, they will generate the same hash-code. A query can then be executed on the hashing-table to find out if a workflow with this particular hash-code is already being processed.
Once a paired-workflow is finished it will remove the hash-code from the hashing-table.
It is recommended to use a "real" database-server for Pairing, like SQL-Server or Oracle (not MS-Access MDB).
Paired Daemons
Pairing Database Configuration
|
Hashing Table
|
Name of the Hashing-table.
The hashing-table contains information which is required to
determine if a workflow is already running on a partner-server; each
time a paired-workflow is executed a hash-code is generated from the
workflow trigger-settings and placed in the hashing-table. If
another partner-server tries to run a workflow with the same
settings this will result in an identical hash-code and cause the
workflow not to be executed. Note-1: The hashing-table is created automatically in case it does not already exist in the database Note-2: Each time a paired daemon is launched, it will make sure no previous entries exist in the hashing-table (cleanup) |
|
Partner
Table |
Name of the Partner-table.
The partner-table contains a list of all running partner-servers.
Each time a partner-server (daemon) is launched it registers itself
in the partner-table and each time a partner-server (daemon) is
shutdown it unregisters itself. Although this table is not actually
used by the pairing proces it can be useful to find out which
servers/daemons are currently paired. Note-1: The partner-table is create automatically in case it does not already exist in the database. |
On-Fail
Option
|
Disable Pairing
|
Pairing is disabled for all
workflows in the daemon and all workflows will run as they would
without the paring-mechanism. NOTE: this could cause problems for workflows/daemons/servers which scan the same hotfolder because they might pickup and proces the same file(s) at the same time. |
|
Stop Daemon
|
The Daemon is stopped. |
|
Restart Daemon
|
The Daemon is restarted after the specified number in seconds. |
Save (Test/Configure)
Save