TRANSACTION

Introduction:
A transaction is a set of changes that must all be made together. It is a program
unit whose execution mayor may not change the contents of a database. Transaction is
executed as a single unit. If the database was in consistent state before a transaction,
then after execution of the transaction also, the database must be in a consistate. For
example, a transfer of money from one bank account to another requires two changes to
the database both must succeed or fail together.
Consider that you are working in a system for a bank. A customer goes to the
ATM and instructs it to transfer Rs. 1000 from savings to a checking account. This
simple transaction requires two steps:
• Subtracting the money from the savings account balance.
• Adding the money to the checking account balance.
The code to create this transaction will require two updates to the database. For
example, there will be two SQL statements: one UPDATE command to decrease the
balance in savings and a second UPDATE command to increase the balance in the
checking account.
What would happen if a machine crashed between these two operations. The
money has already been subtracted from the savings account will not be added to the
checking account. It is lost. You might consider performing the addition to checking
first, but then the customer ends up with extra money, and the bank loses. The point is
that both changes must be made successfully. Thus, a transaction is defined as a set of
changes that must be made together.

Process of Transaction
The transaction is executed as a series of reads and writes of database objects, which are
explained below:
Read Operation
To read a database object, it is first brought into main memory from disk, and then its
value is copied into a program variable as shown in figure.
Write Operation
To write a database object, an in-memory copy of the object is first modified and then
written to disk.

Desirable Properties of a Transaction:

There are four important properties of transaction that a DBMS must ensure to
maintain data in the case of concurrent access and system failures. These are:
Atomicity: ( either all should be done or none should be done)
A transaction is said to be atomic if a transaction always executes all its actions in one
step or not executes any actions at all It means either all or none of the transactions
operations are performed. As a transaction is set of logically related
operations, either all of them should be executed or none. A debit
transaction discussed above should either execute all three operations or
none.If debit transaction fails after executing operation 1 and 2 then its
new value 4000 will not be updated in the database which leads to
inconsistency.
Consistency: (No violation of integrity constraints)
A transaction must preserve the consistency of a database after the execution. The
DBMS assumes that this property holds for each transaction. Ensuring this property of
a transaction is the responsibility of the user.
If operations of debit and credit transactions on same account are executed concurrently, it may
leave database in an inconsistent state.

 For Example, T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A) executing con-
currently, the database reaches inconsistent state.
 Let us assume Account balance of A is Rs. 5000. T1 reads A(5000) and stores the value
in its local buffer space. Then T2 reads A(5000) and also stores the value in its local buf-
fer space.
 T1 performs A=A-1000 (5000-1000=4000) and 4000 is stored in T1 buffer space. Then
T2 performs A=A+500 (5000+500=5500) and 5500 is stored in T2 buffer space. T1
writes the value from its buffer back to database.
 A’s value is updated to 4000 in database and then T2 writes the value from its buffer
back to database. A’s value is updated to 5500 which shows that the effect of debit trans -
action is lost and database has become inconsistent.
 To maintain consistency of database, we need concurrency control protocols which will
be discussed in next article. The operations of T1 and T2 with their buffers and database have
been shown in Table 1.

T1’s buffer T2’s Buffer

T1 T2 Database
space Space
A=5000
R(A); A=5000 A=5000
A=5000 R(A); A=5000 A=5000
A=A-1000; A=4000 A=5000 A=5000
A=4000 A=A+500; A=5500
W(A); A=5500 A=4000
W(A); A=5500

Table 1

Isolation: (concurrent changes invisibles)

The transactions must behave as if they are executed in isolation. It means that if
several transactions are executed concurrently the results must be same as if they were
executed serially in some order. The data used during the execution of a transaction
cannot be used by a second transaction until the first one is completed.
Result of a transaction should not be visible to others before transaction is
committed. For example, Let us assume that A’s balance is Rs. 5000 and T1
debits Rs. 1000 from A. A’s new balance will be 4000. If T2 credits Rs. 500
to A’s new balance, A will become 4500 and after this T1 fails. Then we have
to rollback T2 as well because it is using value produced by T1. So a
transaction results are not made visible to other transactions before it
commits.
Durability: (committed update persist)
The effect of completed or committed transactions should persist even after a crash. It
means once a transaction commits, the system must guarantee that the result of its
operations will never be lost, in spite of subsequent failures.
The acronym ACID is sometimes used to refer above four properties of transaction that
we have presented here: Atomicity, Consistency, Isolation, and Durability.
Once database has committed a transaction, the changes made by the
transaction should be permanent. e.g.; If a person has credited $500000 to
his account, bank can’t say that the update has been lost. To avoid this
problem, multiple copies of database are stored at different locations.

Example
In order to understand above properties consider the following example:
Let, Ti is a transaction that transfers Rs 50 from account A to account B. This
transaction can be defined as:

States of Transaction
A transaction must be in one of the following states:
 Active: the initial state, the transaction stays in this state while it is executing.
 Partially committed: after the final statement has been executed.
 Failed: when the normal execution can no longer proceed.
 Aborted: after the transaction has been rolled back and the database has been
restored to its state prior to the start of the transaction.
 Committed: after successful completion.
The state diagram corresponding to a transaction is shown in Figure.
  Active − In this state, the transaction is being executed. This is the initial state of every
transaction.
 Partially Committed − When a transaction executes its final operation, it is said to be in
a partially committed state.
 Failed − A transaction is said to be in a failed state if any of the checks made by the
database recovery system fails. A failed transaction can no longer proceed further.
 Aborted − If any of the checks fails and the transaction has reached a failed state, then
the recovery manager rolls back all its write operations on the database to bring the
database back to its original state where it was prior to the execution of the transaction.
Transactions in this state are called aborted. The database recovery module can select one
of the two operations after a transaction aborts −
o Re-start the transaction
o Kill the transaction
 Committed − If a transaction executes all its operations successfully, it is said to be
committed. All its effects are now permanently established on the database system.
A transaction starts in the active state. When it finishes its final statement, it enters the
partially committed state. At this point, the transaction has completed its execution, but
it is still possible that it may have to be aborted, since the actual output may still be
temporarily hiding in main memory and thus a hardware failure may preclude its
successful completion
The database system then writes out enough information to disk that, even in the event
of a failure, the updates performed by the transaction can be recreated when the system
restarts after the failure. When the last of this information is written out, the
transaction enters the committed state.