Maintaining transaction consistency between client and server

One disadvantage of using normal ABL transactions on the PAS for OpenEdge is that, because a normal ABL transaction completes and releases all locks before returning to the client, you may have to do extra work to ensure that the transaction completes as the client expects.

A typical scenario where this behavior might pose a problem is where the server returns data derived from a database to a client application. The client then modifies the data and returns it to the server with the intent that the changes to the data are to be applied to the database. Because database locks are not held across interactions with the server, the server cannot simply change the data in the database because the data might have already been changed by another user. Thus, transaction consistency in this situation cannot be easily maintained.

One approach to work around this problem to have the server keep a copy of the original data that is returned to the client application. In a server session, you can maintain a separate buffer or temp-table to hold a copy of the data. You must use the SERVER-CONNECTION-CONTEXT attribute of the SESSION system handle or a context database to maintain a copy of the data. For more information, see the sections on managing unbound session-managed connection context in Programming the Progress Application Server for OpenEdge.

When it is time to apply the updated data, the server session handling the request determines whether the database was changed by another user by comparing the original data to the data in the database. The following figure describes this approach.

The numbers in the previous figure correspond to the following explanation of transaction data flow:

1. The client application runs a remote persistent procedure on the server to request the data. The PAS for OpenEdge instance gets the data from the database and stores it in a temp-table (Orig).

2. As a result of the remote persistent procedure call, the server returns a copy of the Orig temp-table to the client application (Client).

3. The client application makes application-specific changes to its copy (Client~) that include creating, deleting, and modifying records.

4. The client application sends its modified copy (Client~) to the server by running an internal procedure of the persistent procedure instantiated in Step 1. The server stores its copy of the table in Client-Out.

5. Within a single transaction, the server compares the records that are in the Orig temp-table to the data in the database. If there are any differences, the server session knows that the data was changed by another user, aborts the transaction, and notifies the client application that the updates failed.

6. If the data has not been changed (within the same transaction as Step 5), the server then compares the Client-Out table to the Orig table. For each record within the Client-Out table that has been created, modified, or deleted, the server makes the same changes to the data within the database.