The default behavior for handling a lock timeout condition in the OpenEdge DataServers is to return control immediately to the OpenEdge client. Therefore, the lock wait timeout at the data source is set to zero at the beginning of a client session when using the OpenEdge DataServer for MS SQL Server. This is desirable behavior for clients that want immediate control over lock handling. The client application can choose to handle the lock timeout directly using the NO-WAIT and keywords. Then, when a record cannot be accessed because it is locked by another user, the application can test for the server timeout condition by testing for TRUE returned from the LOCKED function. The application consumes the timeout condition in this case and is free to perform whatever action is deemed necessary.
If the client application does not specify NO-WAIT, then the application automatically loops back to the server in an internal wait mode and retries record access. It continues to do so until the Lock Timeout period set on the client (-lkwtmo parameter specified in seconds) is exceeded. If this wait period is exceeded without being able to successfully access the server resource, the process times out, the wait is canceled and the client raises a stop condition.
When NO-WAIT is unspecified, the client consistently returns to the server to retry access to the locked resource. If is also unspecified, then during the Lock Timeout period (-lkwtmo) a resource wait dialog box continues to be displayed to the user. It allows the user to select cancel from the dialog to end the wait period. If the user does not cancel and the -lkwtmo period has not been exceeded, the client performs constant retries and multiple round trips to the server. This constant re-cycling, especially during a period of high resource contention, can be normalized by setting a small timeout period on the server in which to handle lock conditions before returning timeouts to the client application. The server wait period is set through the PRGRS_NATIVE_LOCKWAIT -Dsrv connection parameter. The disadvantage to setting this parameter to a non-zero value is that the client application is blocked for the timeout period set on the server. This may produce some amount of server-bound latency that should be considered when setting the number of milliseconds for this option. However, if the server is able to complete the resource request in the server timeout period, the resource is returned to the client immediately and the application unblocks. Therefore, the advantage of setting a non-zero server timeout is that the server is given the opportunity to resolve record access without further round trips from the client repeatedly request the same resource. A nonzero value may be especially useful during periods of high contention and may increase the overall efficiency of the DataServer application. Progress recommends a nominal but non-zero setting for the number of milliseconds in most cases. Evaluate your average contention for resources in setting this value for your own application.
The PRGRS_NATIVE_LOCKWAIT -Dsrv option permits an application to set a maximum time threshold that the server will block the application waiting to fulfill a resource request that is locked. When the server waits for the resource longer than the PRGRS_NATIVE_LOCKWAIT number of milliseconds, control is returned to the client application which then handles the lock condition as described earlier. As the PRGRS_NATIVE_LOCKWAIT time is increased, the number of retries from the client within the -lkwtmo period is decreased (assuming NO-WAIT is unspecified).
The PRGRS_NATIVE_LOCKWAIT setting will affect all transactions for all connections to the foreign data source for a given application session. This includes read-only connections, stored-procedure connections, and transactions on the sequences connection.
Note: Setting the PRGRS_NATIVE_LOCKWAIT is equivalent to setting the "LOCK_TIMEOUT" value natively in MS SQL Server.
