Release 10.1A: OpenEdge Application Server:
Developing AppServer Applications

> ## Types of AppServer transactions

> An AppServer can allow a client to invoke two different types of transactions in an AppServer agent. The two types of transaction are distinguished by scope (duration) and include the:

> - Normal 4GL transaction

> - Automatic transaction

> ##### Normal 4GL transactions

> A normal 4GL transaction has the scope of part or all of a single remote procedure call. That is, the transaction begins and ends during execution of a single remote procedure request. Thus, all control of the transaction is handled by the AppServer agent within a single request.

> Normal 4GL transactions take full advantage of Progress 4GL built-in transaction management features, such as 4GL-integrated retry and undo (rollback) mechanisms. Normal 4GL transactions yield the smallest possible transaction unit, providing the most efficient handling of record conflicts and transaction resolution. For most applications, this is the only type of transaction that you need to use. It is also the only type of transaction available to previous versions of the AppServer. For more information on managing normal 4GL transactions on an AppServer, see the "Implementing normal 4GL transactions" section.

> ##### Automatic transactions

> An automatic transaction allows the transaction to span more than one remote procedure call. That is, once an automatic transaction is started through some remote procedure call, you can explicitly terminate it in the same procedure call or in a subsequent procedure call running in the same AppServer session. To control this type of transaction, the AppServer provides attributes and methods that you can use to specify how and when you want the transaction to end.

> With automatic transactions, transactions tend to grow large, with greater potential for lock conflicts and other concurrency problems. (For more information on small and large transactions, see the OpenEdge Development: Progress 4GL Handbook .) Even so, automatic transactions can be extremely useful where the application requires the transaction to span multiple AppServer requests. This is especially true where client response is entirely programmatic and does not depend on user interaction for a transaction to complete.

> An example of a useful application might be where a transaction commit depends on a real-time status from a process control or financial trading system. Depending on this status, the AppServer might require additional information from the client to resolve the transaction. As long as the client does not have to wait to make this information available to the AppServer, the impact of the automatic transaction on system performance can be minimal. For more information on managing automatic transactions, see the "Implementing automatic transactions" section.

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