x

An application written for a Shared Application Server achieves its performance benefits, in part, by sharing each server agent among several application users. Each user has sole use of the agent for the duration of a logical transaction. When one user transaction closes (by being committed or rolled back), the next application user gets sole use of the agent for the duration of their logical transaction.

You can maximize performance and minimize bottlenecks by accounting for this sharing behavior: design the logical transactions of your application to be as small as possible, so that the resources of the server agent rotate frequently to each user.

But what would happen if an application were to display a form requiring a user response, and the user left the workstation, causing the logical transaction to pause until he or she returned and responded to the form? The other users of the application on that server agent would be paused indefinitely, unable to proceed until the first user continued.

Maintain avoids this scenario by automatically issuing an implied ROLLBACK command just before the application displays a form. This closes the current transaction, ensuring that while the current user is looking at the form (or is away from the workstation), the transaction of the next user can exploit the resources of the server agent. This ensures high application throughput.

You will probably want to define your application's transaction boundaries yourself, and not have them defined by the automatic rollback prior to each form. You have two options:

• Supply your own change-verify logic. You can code your own change-verify logic to verify, before writing each record, that it has not been changed by other users since you initially read it for the current transaction. This requires locking each record while it is being retrieved, releasing the lock, working with the data, and then relocking it shortly before writing it to the data source. This technique ensures transaction integrity by verifying, before writing a record, that other users have not changed it in the interim.

  For more information about this technique, see Ensuring Transaction Integrity. Although the technique is described there for use with DB2 data sources, you can apply it to transactions against other kinds of data sources, changing DBMS-specific details when necessary.

• Display no forms within a transaction. You can choose to display all forms before, or after, transaction logic, but not in the middle of its logic. This works well for applications that can separate presentation logic from transaction logic. For example, you may have a batch update application that displays some menu forms to enable a user to select different options, and then begins a transaction using data from a transaction file.