Building Distributed
Applications
Using the Progress AppServer


Comparing Normal 4GL and Automatic Transactions

Normal 4GL transactions are designed to keep transaction scope very small, within the context of a single remote procedure call. Small transactions minimize the chances of conflict during concurrent accesses to a single database. This type of transaction is also identical to the type of transaction supported for 4GL clients.

Because automatic transactions can remain active for multiple remote procedure calls, the scope of these transactions expands accordingly. This expanded scope allows much greater opportunity for conflict during concurrent accesses to a single database. As a result, you must be very cautious about how you use automatic transactions.

For example, you might provide an interface that closely mirrors the actual transaction mechanics, called from the client like this:

RUN startTransaction.p ON SERVER ...
RUN commitTransaction.p ON SERVER ... 

Another example is the interface provided by a-txtest.p (see "Programming the AppServer").

However, you might better simplify this process for the client with a more abstract interface, called from the client like this:

RUN initiateCustomerUpdate.p ON SERVER ...
RUN finishCustomerUpdate.p ON SERVER .... 

These examples appear to accomplish the same thing. However, the first example implies that remote procedure return values monitor the transaction mechanism, while the second example implies that the remote procedure return values monitor the status of customer information. A well-designed outcome of the second example might be your guaranteeing that finishCustomerUpdate.p always commits the transaction appropriately, without the client having to be concerned with it.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095