Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

> ## 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 Progress 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 Chapter 2 "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 © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095