All AppServer 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 AppServer access the same database, each one accesses the database as a different user, whether or not the client is connected to the AppServer. As a result, any combination of AppServer clients and AppServer 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 OpenEdge Getting Started: ABL Essentials.)
Thus, it is important when performing direct database access from both client and AppServer 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 AppServer, 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 AppServer session (specified as part of the srvrStartupParam property value in your AppServer 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 OpenEdge Deployment: 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 AppServer. The data source is managed solely by the AppServer, 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:
