OpenEdge Data Management: DataServer for Microsoft SQL Server

Handling lock timeouts
Data source record locking
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 NO-ERROR 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 NO-ERROR 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.
OpenEdge Data Management: DataServer for Microsoft SQL Server 95