DBMS 15
DBMS 15
Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's account.
This small transaction contains several low-level tasks:
X's Account
1. Open_Account(X)
2. Old_Balance = X.balance
3. New_Balance = Old_Balance - 800
4. X.balance = New_Balance
5. Close_Account(X)
Y's Account
1. Open_Account(Y)
2. Old_Balance = Y.balance
3. New_Balance = Old_Balance + 800
4. Y.balance = New_Balance
5. Close_Account(Y)
Operations in Transaction-
The main operations in a transaction are-
1. Read Operation
2. Write Operation
1. Read Operation-
Read operation reads the data from the database and then stores it in the buffer in
main memory.
For example- Read(A) instruction will read the value of A from the database and will
store it in the buffer in main memory.
2. Write Operation-
Write operation writes the updated data value back to the database from the buffer.
For example- Write(A) will write the updated value of A from the buffer to the
database.
Let's take an example to debit transaction from an account which consists of following
operations:
1. R(X);
2. X = X - 500;
3. W(X);
Let's assume the value of X before starting of the transaction is 4000.
The first operation reads X's value from database and stores it in a buffer.
The second operation will decrease the value of X by 500. So buffer will contain 3500.
The third operation will write the buffer's value to the database. So X's final value will
be 3500.
But it may be possible that because of the failure of hardware, software or power, etc. that
transaction may fail before finished all the operations in the set.
For example: If in the above transaction, the debit transaction fails after executing
operation 2 then X's value will remain 4000 in the database which is not acceptable by the
bank.
To solve this problem, we have two important operations:
Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.
Transaction States-
A transaction goes through many different states throughout its life cycle.
These states are called as transaction states.
Transaction states are as follows-
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Aborted state
6. Terminated state
1. Active State-
This is the first state in the life cycle of a transaction.
A transaction is called in an active state as long as its instructions are getting
executed.
All the changes made by the transaction now are stored in the buffer in main
memory.
3. Committed State-
After all the changes made by the transaction have been successfully stored into the
database, it enters into a committed state.
Now, the transaction is considered to be fully committed.
NOTE-
After a transaction has entered the committed state, it is not possible to roll back the
transaction.
In other words, it is not possible to undo the change that has been made by the
transaction.
4. Failed State-
When a transaction is getting executed in the active state or partially committed state
and some failure occurs due to which it becomes impossible to continue the
execution, it enters into a failed state.
5. Aborted State-
After the transaction has failed and entered into a failed state, all the changes made
by it have to be undone.
To undo the changes made by the transaction, it becomes necessary to roll back the
transaction.
After the transaction has rolled back completely, it enters into an aborted state.
6. Terminated State-
This is the last state in the life cycle of a transaction.
After entering the committed state or aborted state, the transaction finally enters into
a terminated state where its life cycle finally comes to an end.
ACID Properties-
It is important to ensure that the database remains consistent before and after the
transaction.
To ensure the consistency of database, certain properties are followed by all the
transactions occurring in the system.
These properties are called as ACID Properties of a transaction.
1. Atomicity-
This property ensures that either the transaction occurs completely or it does not
occur at all.
Example: Let's assume that following transaction T consisting of T1 and T2. A consists of
Rs 600 and B consists of Rs 300. Transfer Rs 100 from account A to account B.
T1 T2
Read(A) Read(B)
A:= A-100 Y:= Y+100
Write(A) Write(B)
If the transaction T fails after the completion of transaction T1 but before completion of
transaction T2, then the amount will be deducted from A but not added to B. This shows
the inconsistent database state. In order to ensure correctness of database state, the
transaction must be executed in entirety.
2. Consistency-
This property ensures that integrity constraints are maintained.
In other words, it ensures that the database remains consistent before and after the
transaction.
It is the responsibility of DBMS and application programmer to ensure consistency of
the database.
For example: The total amount must be maintained before or after the transaction.
1. Total before T occurs = 600+300=900
2. Total after T occurs= 500+400=900
Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.
3. Isolation-
This property ensures that multiple transactions can occur simultaneously without
causing any inconsistency.
During execution, each transaction feels as if it is getting executed alone in the
system.
A transaction does not realize that there are other transactions as well getting
executed parallel.
A change made by a transaction becomes visible to other transactions only after they
are written in the memory.
The resultant state of the system after executing all the transactions is same as the
state that would be achieved if the transactions were executed serially one after the
other.
It is the responsibility of concurrency control manager to ensure isolation for all the
transactions.
4. Durability-
This property ensures that all the changes made by a transaction after its successful
execution is written successfully to the disk.
It also ensures that these changes exist permanently and are never lost even if there
occurs a failure of any kind.
It is the responsibility of recovery manager to ensure durability in the database.
NOTE-
Dirty read does not lead to inconsistency always.
It becomes problematic only when the uncommitted transactions fails and roll backs
later due to some reason.
Example-
Here,
1. T1 reads the value of A.
2. T1 updates the value of A in the buffer.
3. T2 reads the value of A from the buffer.
4. T2 writes the updated the value of A.
5. T2 commits.
6. T1 fails in later stages and rolls back.
In this example,
T2 reads the dirty value of A written by the uncommitted transaction T1.
T1 fails in later stages and roll backs.
Thus, the value that T2 read now stands to be incorrect.
Therefore, database becomes inconsistent.
Here,
1. T1 reads the value of X (= 10 say).
2. T2 reads the value of X (= 10).
3. T1 updates the value of X (from 10 to 15 say) in the buffer.
4. T2 again reads the value of X (but = 15).
In this example,
T2 gets to read a different value of X in its second reading.
T2 wonders how the value of X got changed because according to it, it is running in
isolation.
This problem occurs when multiple transactions execute concurrently and updates from
one or more transactions get lost.
Example-
Here,
1. T1 reads the value of A (= 10 say).
2. T2 updates the value to A (= 15 say) in the buffer.
3. T2 does blind write A = 25 (write without read) in the buffer.
4. T2 commits.
5. When T1 commits, it writes A = 25 in the database.
In this example,
T1 writes the over written value of X in the database.
Thus, update from T1 gets lost.
NOTE-
This problem occurs whenever there is a write-write conflict.
In write-write conflict, there are two writes one by each transaction on the same data
item without any read in the middle.
This problem occurs when a transaction reads some variable from the buffer and when it
reads the same variable later; it finds that the variable does not exist.
Example-
Here,
1. T1 reads X.
2. T2 reads X.
3. T1 deletes X.
4. T2 tries reading X but does not find it.
In this example,
T2 finds that there does not exist any variable X when it tries reading X again.
T2 wonders who deleted the variable X because according to it, it is running in
isolation.
Parallel Schedules − In parallel schedules, more than one transactions are active
simultaneously, i.e. the transactions contain operations that overlap at time. This is
depicted in the following graph −
Conflicts in Schedules
In a schedule comprising of multiple transactions, a conflict occurs when two active
transactions perform non-compatible operations. Two operations are said to be in conflict,
when all of the following three conditions exists simultaneously −
The two operations are parts of different transactions.
Both the operations access the same data item.
At least one of the operations is a write_item() operation, i.e. it tries to modify the
data item.
Serializability
A serializable schedule of ‘n’ transactions is a parallel schedule which is equivalent to a
serial schedule comprising of the same ‘n’ transactions. A serializable schedule contains the
correctness of serial schedule while ascertaining better CPU utilization of parallel schedule.
Equivalence of Schedules
Equivalence of two schedules can be of the following types −
Result equivalence − Two schedules producing identical results are said to be result
equivalent.
View equivalence − Two schedules that perform similar action in a similar manner are
said to be view equivalent.
Conflict equivalence − Two schedules are said to be conflict equivalent if both contain the
same set of transactions and has the same order of conflicting pairs of operations.
Controlling Concurrency
Concurrency controlling techniques ensure that multiple transactions are executed
simultaneously while maintaining the ACID properties of the transactions and
serializability in the schedules.
In this section, we will study the various approaches for concurrency control.
Locking Based Concurrency Control Protocols
Locking-based concurrency control protocols use the concept of locking data items.
A lock is a variable associated with a data item that determines whether read/write
operations can be performed on that data item. Generally, a lock compatibility matrix is
used which states whether a data item can be locked by two transactions at the same time.
Locking-based concurrency control systems can use either one-phase or two-phase locking
protocols.
One-phase Locking Protocol
In this method, each transaction locks an item before use and releases the lock as soon as
it has finished using it. This locking method provides for maximum concurrency but does
not always enforce serializability.
Two-phase Locking Protocol
In this method, all locking operations precede the first lock-release or unlock operation. The
transaction comprise of two phases. In the first phase, a transaction only acquires all the
locks it needs and do not release any lock. This is called the expanding or the growing
phase. In the second phase, the transaction releases the locks and cannot request any new
locks. This is called the shrinking phase.