Building Distributed
Applications
Using the Progress AppServer


Types of AppServer Transactions

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

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 Application Server process within a single request.

Normal 4GL transactions take full advantage of Progress 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 Progress AppServer. For more information on managing normal 4GL transactions on an AppServer, see the "Implementing Normal 4GL Transactions" section in this chapter.

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 Progress Programming 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 in this chapter.


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