The Concurrent Transactions

 Almost every commercial DBMS support multi-user environment. Therefore, allowing multiple transactions to proceed concurrently. The DBMS must make sure that two or more transactions do not obtain into each other's way, i.e., transaction of one user doesn't effect the transaction of other or even the transactions issued by the similar user should not get into the way of each other. Be advised that concurrency related problem may happen in databases only if two transactions are contending for the similar data item and at least one of the concurrent transactions wishes to update a data value in the database. In this, the concurrent transactions only read similar data item and no updates are done on these values, then it does NOT create any concurrency related difficulty. Now, let us talk about why you require a mechanism to control concurrency.

Consider a banking application dealing with saving and checking accounts. A Banking Transaction T1 for Mr. Sharma moves Rs.100 from his checking account balance X to his savings account balance Y, using the transaction T1:

Transaction T1:

A:  Read X

Subtract 100

Write X

B:   Read Y

 Add 100

Write Y

Let us assume an auditor wants to know the total assets of Mr. Sharma. He implements the following transaction:

Transaction T2:

Read X Read

Y Display

X+Y

Assume both of these transactions are issued concurrently, and then the implement of these instructions can be combined in many ways. This is also known as the Schedule. Let us describe this term in more detail.

A schedule S is described as the sequential ordering of the operations of the 'n' interleaved transactions. A schedule keeps the order of operations within the individual transaction.

                   One possible schedule for interleaved execution of TA and TB