Try OpenEdge Now
skip to main content
Developing AppServer Applications
Design and Implementation Considerations : Primary performance considerations : Choosing a transaction model
 

Choosing a transaction model

The client application and AppServer run in two separate sessions. Transactions are not propagated between these sessions. However, the AppServer supports two types of transactions:
*Normal ABL transactions — Where a single transaction begins and ends within the scope of a single remote procedure request from the client. The AppServer starts and manages the transaction within the scope of the remote procedure in exactly the same way an ABL client starts and manages a transaction within a local client procedure.
*Automatic transactions —Where a single transaction can span multiple remote procedure requests from the client. The AppServer can terminate the transaction at any time from the moment it starts until the end of the connection.
The choice of which type of transaction to use depends entirely upon the nature of your application. By definition, automatic transactions that span more than one remote procedure request tend to be larger than normal ABL transactions (assuming similar data transfers per request). Also, between multiple client requests with an open automatic transaction, there is more opportunity to make the transaction even larger if UI interactions occur on the client that effectively become part of the same transaction. This, in turn, creates more opportunity for lock conflicts and deadlocks among database clients, including the AppServer session.
For more information on trade-offs and issues for both types of transactions, see Transaction and record management considerations.