Normal ABL 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 ABL 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, as shown:
RUN startTransaction.p ON SERVER ...
RUN commitTransaction.p ON SERVER ...
However, you might better simplify this process for the client with a more abstract interface, called from the client, as shown:
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.
