Transactions

In many cases, the application server provides transaction management. This is determined when your component is placed under the control of the application server.

If the application server is not providing transaction management, it must use OpenESQL COMMIT and ROLLBACK statements to manage transactions.

If, however, the application server is providing transaction management, the following applies:

• If connection management is not provided by the application server (that is, your application uses CONNECT and DISCONNECT statements), you can use one of the following to handle transactions:
  • Set the TRANSACTION primitive directive of the BEHAVIOR SQL compiler directive option (recommended).
  • Set the AUTOCOMMIT SQL compiler directive option to enable your application to handle transactions using COMMIT and ROLLBACK statements.
  • Use the application server to provide API calls or return codes for you to signal success or failure.

If you are using MTS or COM+, the default transaction isolation level, when the application server is managing transactions, can be serialized. This might cause excessive locking, and reduce concurrency. Your application must be prepared to deal with its transaction being aborted when the application server attempts to resolve a deadlock. To ease these problems, you can use the following statement:

exec sql set transaction isolation read committed end-exec

to set a less stringent isolation level. In this case, the statement must be the first statement to be executed after the CONNECT statement. Note that when SQL(AUTOCOMMIT) is not used, a commit or rollback is required immediately prior to executing a SET TRANSACTION ISOLATION statement.