Time to maintain locks for connection recovery

WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows



The SCSKEEPLOCKS environment variable enables the client to override the KeepLocks value on the server when using xfServer connection recovery.

The maximum number of seconds to maintain record locks when a client context is saved. Valid values are 0 through 43200 (12 hours).

When connection recovery is enabled on the server (in either slave or master mode), setting SCSKEEPLOCKS on the client overrides the KeepLocks value set on the xfServer machine for that client. The value of SCSKEEPLOCKS should not be larger than that of SCSKEEPCONTEXT because locks cannot be maintained after a client context has expired.


Take care when setting a value for SCSKEEPLOCKS. In most cases, a relatively short time—no more than 5 minutes—should suffice. A longer time runs the risk that the user may give up waiting for the socket to reconnect, exit and restart the application, and then discover that records cannot be accessed because they are still locked.

When connection recovery is enabled in slave mode, setting SCSKEEPLOCKS on the client enables the feature for that client, even if SCSKEEPCONNECT is not set. (If SCSKEEPCONNECT is explicitly set to OFF or if KeepConnect on the server is off, setting SCSKEEPLOCKS will not enable the feature, and a warning will be logged in the Windows event log on the server.)

If SCSPROFILE is also set, the value set with SCSKEEPLOCKS will override the KeepLocks setting in the specified profile.

If KeepLocks is set to non-zero on the server and you wish to disable this aspect of connection recovery for a specific client, set SCSKEEPLOCKS to 0. This will ensure that all record locks held by that client are released as soon as an unexpected socket disconnect is detected.

On the xfServer client in the environment or in the [dbr] section of synergy.ini. To use the SETLOG routine to set SCSKEEPLOCKS, call it prior to the first OPEN statement to the server.