Application processes and transactions

Many different types of programs access DB2 data: user-written applications, SQL statements that users enter dynamically, and even utilities. The single term that describes any type of access to DB2 data is called an application process. All SQL programs run as part of an application process. An application process involves running one or more programs. Different application processes might involve running different programs or running the same program at different times.

When an application interacts with a DB2 database, a transaction begins. A transaction is a sequence of actions between the application and the database; the sequence begins when data in the database is read or written. A transaction is also known as a unit of work.

Example: Consider what happens when you access funds in a bank account. A banking transaction might involve the transfer of funds from one account to another. During the transaction, an application program first subtracts the funds from the first account, and then it adds the funds to the second account. Following the subtraction step, the data is inconsistent. Consistency is reestablished after the funds have been added to the second account.

To ensure data consistency, DB2 uses a variety of techniques that include a commit operation, a rollback operation, and locking.

When the subtraction and addition steps of the banking transaction are complete, the application can use the commit operation to end the transaction, thereby making the changes available to other application processes. The commit operation makes the database changes permanent.

Consider what happens if more than one application process requests access to the same data at the same time. Or, under certain circumstances, an SQL statement might run concurrently with a utility on the same table space. DB2 uses locks to maintain data integrity under these conditions to prevent, for example, two application processes from updating the same row of data simultaneously.

DB2 acquires locks to prevent uncommitted changes that are made by one application process from being perceived by any other. DB2 automatically releases all locks it has acquired on behalf of an application process when that process ends, but an application process can also explicitly request that locks be released sooner. A commit operation releases locks that an application process has acquired and commits database changes that were made by the same process.

DB2 also provides a way to back out uncommitted changes that an application process makes. This might be necessary in the event of a failure on the part of an application process or in a deadlock situation. Deadlock occurs when contention for the use of a resource, such as a table, cannot be resolved. An application process, however, can explicitly request that its database changes be backed out. This operation is called rollback. The interface that an SQL program uses to explicitly specify these commit and rollback operations depends on the environment. For example, in the JDBC environment, applications use commit and rollback methods to commit or roll back transactions.