Transactions

For the DB2 access service, a transaction is equivalent to a unit of work (one or more requests). A transaction can span many requests.

Depending on DB2 access service property settings, the TransactionMode property that governs transaction behavior can be set to either short or long.

When short transactions are in effect, the DB2 access service is responsible for controlling the commitment of requests. After sending the request to the database, the DB2 access service automatically issues one of the following:

• A commit, if the request succeeds

• A rollback, if the request fails

  While in short transaction mode, the request is a unit of work.

A begin transaction phrase can affect the behavior of a short transaction. If it receives a begin transaction phrase, the DB2 access service:

• Triggers a commit of all previous statements in the request.

• Temporarily sets TransactionMode to long, although a select @@TransactionMode command returns an answer of short mode. While in temporary long mode, if the batch processes successfully, the SQL statements are committed.

• Stays in temporary long transaction mode until a unit of work is completed with a commit or rollback. Then, the DB2 access service reverts TransactionMode to short.

  Do not change configuration properties while the request is in temporary long mode. Once a commit or rollback occurs, the temporary long mode reverts to short mode.

When long transactions are in effect, the client application is responsible for controlling when the transaction ends (by issuing either a commit or a rollback).

If the DB2 access service encounters a begin transaction phrase in a request, the phrase is ignored because the phrase does not affect the unit of work management.

The client application issues a commit or rollback statement for each transaction. When the client application closes its connection, the DB2 access service issues a rollback before exiting. Therefore, the client must commit any work that should be committed.

If the client application does not issue timely commit or rollback operations, then host resources (such as the APPC session or DB2 logging and locking) are held for an indeterminate amount of time. Therefore, long transactions can cause performance problems for other applications that need to access the same resource.