All server transactions (normal or automatic) occur in a context that is separate and distinct from the client. One way of understanding this is that if both a client and an server access the same database, each one accesses the database as a different user, whether or not the client is connected to the server. As a result, any combination of server clients and server sessions can cause lock contention with each other as multiple database clients of the same database. (For more information on locks and lock contention, also known as deadlock, see Develop ABL Applications.)

Thus, it is important when performing direct database access from both client and server sessions that you avoid or otherwise manage the possibility that all of these sessions might concurrently access the same record. If they do, and you attempt to run a transaction that changes the record on either the client or the server, the SHARE-LOCK held by each one will prevent the record from being changed, and ultimately the transaction from being committed. If the continued execution of both the client and any Application Sever session depends on the transaction being completed, then a deadlock occurs that prevents the entire application from continuing.

To avoid a deadlock, you can use the Lock Wait Timeout (-lkwtmo) startup parameter for both an ABL client and the server session (specified as part of the sessionStartupParam property value in your PAS for OpenEdge openedge.properties file). This parameter sets a limited time that any ABL procedure must wait to continue execution because of a lock. For more information on this parameter, see Startup Command and Parameter Reference. However, this is not a solution to any fundamental design problems that might avoid the conflict altogether, such as an application that does not conform to the OERA.

The OpenEdge Reference Architecture (OERA), the Progress Software Corp. guide for designing OpenEdge enterprise applications, avoids the problem of client-server lock contention completely. In an application whose design conforms to the OERA, a client never accesses the enterprise data source and thus can never have a deadlock with the server. The data source is managed solely by the server, which also manages all exchange of enterprise data with the client.

However, if you cannot redesign your application to avoid this type of lock contention, you can code as described in the following sections.