Table of Contents

Search

  1. Preface
  2. Introduction
  3. Servers
  4. Console Client
  5. Search Clients
  6. Table Loader
  7. Update Synchronizer
  8. Globalization
  9. Siebel Connector
  10. Web Services
  11. ASM Workbench
  12. Cluster Merge Rules
  13. Forced Link and Unlink
  14. System Backup and Restore
  15. Batch Utilities

Restarting

Restarting

All servers (Connection Server, combined Search/Rulebase Servers and Console Server) are launched as a pair of processes. The first process spawns a second server process that acts as the real server that clients connect to. If the spawned server crashes, the parent process automatically spawns a new copy of itself. This provides a degree of fault tolerance.

Rulebase Server

The Rulebase Server has special restart requirements because it uses a locking mechanism to protect itself. The locking mechanism prevents two Rulebase Servers updating the same Rulebase tables.
When a parent Rulebase server starts, it generates a unique Id and passes it to the child server. When the child opens the Rulebase it saves the Id in the Rulebase.
If another Rulebase server attempts to open the same Rulebase, its Id will not match the value held in the Rulebase and an error message similar to this is displayed:
Rulebase is locked Rulebase In use by ssa.identitysystems.com IP=203.2.203.105 on port=1668, ID=271259152 IS ANOTHER RULEBASE SERVER RUNNING?

Automatic Restart

If the child server crashes, the parent server spawns a new child with the same Id as the original child.
When the child server starts and finds an Id already present, it compares it to the parent’s. If they are the same it displays the following message and restarts successfully:
This is an automatic restart

Manual Restart

If the computer crashes (and all processes terminate), the Rulebase remains locked. The next time a new pair of parent/child Rulebase Servers are started, the parent generates a new unique Id. It will not match the Id stored in the Rulebase, so the child server will fail to start. In this situation, you can manually override the lock by setting an environment variable to the same Id that currently locks the Rulebase. For example,
SSA_RB_RESTART_ID=271259152
When the Rulebase server is started, it will use the environment variable to unlock the Rulebase (as long as the two Ids match). It will then use the freshly generated parent Id to re-lock it. Therefore the environment variable can only be used once to unlock the database. A manual restart generates the following message in the server log:
This is a manual restart

Automatically Restarting After Common Failures

A manual restart is usually required after a power outage or reboot. When
SSA_RB_RESTART_ID
is set to 0, MDM-RE will automatically attempt to detect if the original process that locked the Rulebase is still running. If it is not, the restart will be automatic (with no intervention required).
IS ANOTHER RULEBASE SERVER RUNNING? Rulebase ’sdb:file:c:\a3i\ids\rule’ In use by ssa.identitysystems.com IP=203.2.203.109 on port=1668, SSA_RB_RESTART_ID=281728582 Other RB information: ip=203.2.203.109 pid=299 host=’ssa.identitysystems.com’ ps=’2002/11/28 06:29:10.8233’ Other RB server not running This is an automatic restart
However, if the original job is running, or its status cannot be determined, MDM-RE will not automatically unlock the Rulebase.
When
SSA_RB_RESTART_ID
is set to 0 it is possible to inadvertently start multiple Rulebase servers. If this occurs, Rulebase corruption will result. We strongly recommend that
SSA_RB_RESTART_ID
is not left in any start-up script or in the environment after a server restart.
This facility requires that various operating system functions will return consistent results. For example, the host name of the machine and the output of the
ps
command must return the same result when called repeatedly. Any inconsistencies may result in the Server concluding that the previous server is no longer running and to start a second instance. If the previous server is still running, Rulebase corruption may result.

Connection Aliases

Users must not connect to the same Rulebase Server using multiple userids or service names that are aliases for the same physical rulebase.
For example, if the service names Jupiter and Mars are aliases for the same Oracle service, all rulebase connection strings must specify either Jupiter (or Mars) but must not use a mixture. Similarly, when using Oracle’s Operating System Authentication feature, a connection string that explicitly provides a userid may be an alias of one that does not, as they may both be routed to the same physical rulebase. In this case, use one consistent form for the connection string, or consider using a dictionary alias.
The rulebase name is used to identify a cache containing updated rulebase data. The use of alias names will create multiple caches, which will be written to the same physical rulebase, causing corruption.
MDM-RE will detect if an alias is used and refuse to open the connection, stating that the rulebase is already owned by another user.

0 COMMENTS

We’d like to hear from you!