In this section: |
This section describes how you can control transactions using the API. It covers the following topics:
A transaction can have many definitions, but for the purposes of the server, it is defined as a collection of server methods that interact with the application data. Sometimes this is referred to as a Unit of Work (UOW) or a Logical Unit of Work (LUW). If the server methods used are read-only (that is, they use only the SQL SELECT verb), the only data that the transaction changes is system data (such as cursors and locks). If SQL verbs such as INSERT, UPDATE, and DELETE are used, application data is changed, and care must be taken when designing the application to ensure that transactions are correctly executed, even in the event of system failures.
A phrase often used in the context of transaction management is Two-phase Commit. This is a technique used by transaction managers to ensure that transactions are executed completely or not at all. The server is not a general transaction manager and provides a two-phase commit only in specific circumstances:
For example, if your transaction updates two different databases and both provide resource managers, the server will act as a transaction manager to provide two phase commit support for these data bases.
Scope and Control of Server Transactions
The following sections describe the scope of server transactions; that is, which server methods will be included in a transaction. These sections also describe how you can control that scope by either letting the API issue commits (auto commit and presumed commit) or by issuing SQL COMMIT WORK or EDACOMMIT yourself.
You can choose whether to control commitment yourself or whether to commit at every SQL command by using the EDA_VAR_AUTOCOMMIT variable setting. By default, the API will tell the server to commit at every SQL command, so only the current command is part of the transaction. This is illustrated in the following figure.
When the physical connection to a particular server is ended, the API will send a commit to the server. All methods issued since the last commit (if any) will now be made part of the same transaction. This means that, in many cases, you need never use the explicit EDACOMMIT method to control your transactions. If the client loses its connection with the server without issuing EDAXCONNECT, the server will rollback the outstanding work.
Note: A commit is not necessarily sent with each EDAXCONNECT method call. It will only be sent if that connection represents the only remaining connection to a particular server task.
SQL COMMIT WORK is a server-level command and will be passed by the API to the server for which it was issued. In turn, the server will commit all the databases for which it has connections. Each database committed will create a separate transaction for the calls made to it by your program. The following figure shows the API scope of SQL COMMIT. Semiplexing is ignored in this diagram:
In the case of more than one SCB operating against a single server (semiplexing), the SQL COMMIT WORK will apply to the set of connections that are shared. The following figure shows the API scope of SQL COMMIT work (with two active servers, each semiplexed with two SCBs).
Note: If the same database is used for the two semiplexed transactions, they will become part of the same transaction. This is because they will be running under control of a single transaction manager in the database.
The EDACOMMIT method call will cause the API to send SQL COMMIT WORK to every server to which the user is connected. This is shown in the following figure.
Note: EDACOMMIT will also release any pending data on all open SCBs. Therefore, EDACOMMIT should not be called until processing on all active SCBs is completed.
Note: Because the transaction managers are in the databases and not in the servers or API, each SQL call from a database will form a separate transaction.
| iWay Software |