Deploying Client Distributed Lock

Specifies the primary lock service specification.

Specifies the secondary lock service specification for resilience.

Specifies either the DNS hostname or the dotted IP address of the system where the jBASE Distributed Lock Service is executing.

The WAIT option can be used to control the action of distributed lock retries. If this option is configured, then the client will wait for acknowledgement that the lock request has been completed without any interim communication, (see “distributed lock retries”).

With this option, setting up of default acknowledgement timeout period is not used. This option is not recommended as processes may wait a considerable time in case of lock contention without update to the lock status of the process.

The TIMEOUT option can be used to override the timeout period, within which any distributed lock request must be acknowledged. The default timeout period is set for 30 seconds. This period allows for multiple retries for the lock on the server system, as such should only be adjusted upward.

The BINARY option can be used to intercept all binary type locks, that is locks other than record locks and redirect them to the Distributed Lock Service. Locks that would normally be taken on the local system will be intercepted and redirected to the Distributed Lock Service, such that they can be propagated and hence respected across multiple systems. This option should not be required except when using jBASE Hash files over NFS and/or File and Execution Locks.

The OSLOCKS option can be used to force all record locks to be routed via the OS file lock path such that OS file locks are taken on the Distributed Lock Service Server by default rather than using the configured lock mechanism on the lock server.

The LOCK option can be used to differentiate the interception of locks for internal or external lock handlers. The default is for all locks both internal and external to be intercepted and redirected to the Distributed Lock Service. However, certain external database drivers may require their own lock functions to be invoked, in which case the LOCK option should be set to INTERNAL. RDBMS drivers use INTERNAL locking and hence the default configuration or INTERNAL value will redirect all record locks required for the application irrespective of the underlying RDBMS locking schemes.