Database Ownership
Each adTempus instance uses its own database to store configuration information. To ensure that only one instance is ever using a database at the same time, the adTempus service saves locking information in the database while it is running. It periodically records a "heartbeat" update to the database indicating that it is still active, and when it shuts down it releases its lock on the database. On startup, the service checks to see if the database already belongs to another instance. If so, it determines whether the other instance is active:
-
If the other instance shut down normally, it released its lock on the database. The new instance starts normally but records a message in the Event Viewer and the Alerts view indicating that it has taken control from another instance.
-
If the database still contains a lock by the other instance, the new instance checks to see when the last heartbeat was recorded by the other instance.
-
If enough time has passed (5 minutes, by default) the new instance assumes that the other instance is no longer active (e.g., due to a computer, software, or network failure). The new instance starts normally but records a message in the Event Viewer and the Alerts view indicating that it has taken control from another instance.
-
If the time delay has not passed, the adTempus service will fail to start, and will log the following error message in the Application log in the Event Viewer:
If you know that it is safe to start the new instance (for example, you have copied the database, or you know that the other instance has been stopped), you can use the "-takedbcontrol" startup option to force the service to start. Alternatively you can wait until the delay time has passed and then start the service.
-
This locking mechanism is new for adTempus 5. Earlier versions used a different locking mechanism (see the version 4 user guide for more information). Future versions of adTempus may use this heartbeat information to support automatic failover.