Showing posts with label Concurrency Control. Show all posts
Showing posts with label Concurrency Control. Show all posts

Thursday, April 21, 2016

Concurrency Anomalies - Incorrect Summary Problem

Need for concurrency control, Concurrency Anomalies, Concurrent Execution Problems
Incorrect Summary / Inconsistent Analysis problem

This problem is caused when one of the transactions is executing an aggregate operation on several data items, and other transactions are updating one or more of those data items. This causes a inconsistent database state.

Example:

Consider the schedule S1 given below, in which, transaction T1 transfers money from account A to account B and in the mean time, transaction T2 calculates the sum of 3 accounts namely, A, B, and C. The third column shows the account balances and calculated values after every instruction is executed.

Transaction T1
Transaction T2
A = 1000, B = 1000, C = 1000




read(A);
A := A – 50;
write(A);






read(B);
B := B + 50;
write(B);
commit;
sum = 0;
avg = 0;
read(C);
sum := sum + C;



read(A);
sum := sum + A;
read(B);
sum := sum + B;
avg := sum/3;
commit;
sum  = 0
avg = 0
T2 read: C = 1000
sum = 1000
T1 read: A = 1000

T1 write: A = 950
T2 read: A = 950
sum = 1950
t2 read: B = 1000
sum = 2950
avg = 983.33

T2 read: B = 1000

T2 write: B = 1050

Discussion:

Transaction T2 reads the value of account A after A is updated and reads B before B is updated. [The portion that violates in T2 is highlighted in green color]. Hence, the aggregate operation is end up with an inconsistent result.
If all the instructions in T1 are executed before T2 starts, then A will be 950, B will be 1050 and average value will be 1000.
If all the instructions in T1 are executed after T2 finishes, then A will be 950, B will be 1050 and average value will be 1000.
But, due to this interleaved execution, the final value of A is 950, B is 1050, and average is 983.33 which is wrong.
This problem is called as Inconsistent analysis or Incorrect summary problem. This is caused due to the interleaved execution of multiple simultaneous transactions that are working on same data items.

******************

Go to Transaction Management in DBMS home page









Monday, April 18, 2016

Concurrency Anomalies - Uncommitted Read Problem



Need for concurrency control, Concurrency Anomalies, Concurrent Execution Problems

Reading Uncommitted Data / Temporary Update / Dirty Read Problem


This problem is caused when one transaction is permitted to read a data item that is modified by an uncommitted transaction. It will cause us trouble if the uncommitted transaction decided to rollback.

For example, if a transaction T1 has modified a data item Q and if a transaction T2 is allowed to read the value of Q as modified by T1 before T1 commits, then it causes dirty read problem. Here, the read operation performed by T2 is called dirty read.

Example:

To explain this concept, let us use the schedule s1 given below;
Here, transaction T1 transfers 50 from account A to B, and transaction T2 calculates the 10 % interest on the balance of A and credits A with the interest.
Transaction T1
Transaction T2
A = 1000, B = 1000
read(A);
A := A – 50;
write(A);





read(B);
B := B + 50;
write(B);
commit;



read(A);
temp := A * 0.1;
A := A + temp;
write(A);
commit;
T1 read: A = 1000

T1 write: A = 950
T2 read: A = 950 (read uncommitted data)


T2 write: A = 1045

T1 decided to rollback.
Table: Schedule S1
Let us suppose the initial value of A and B are 1000;

  • The transaction T1, at first, read the value of A (ie., 1000).

  • Then T1 is writing account A with 950 after calculation.

  • Now transaction T2 reads the value of A that is written by T1 and consecutively calculated the interest value. Also, T2 has committed by writing 1045 into A.

  • In the mean time T1 is decided to roll back for some reason.

At this point, if T1 is rolled back, that makes the value 950 to be rolled back to 1000. But the interleaved transaction T2 has used that uncommitted value (950) which does not exist now. This read by T2 is called dirty read. And, this lead the database to an inconsistent state.

Discussion:

  • The process of allowing another transaction to view the intermediate results (not yet committed) of a transaction before it commits causes this problem. This is violating the Isolation property of transactions.

  • It is caused due to Write-Read conflict between transactions.



***********************

Go to Transaction Management in DBMS home page

Go to Need for Concurrency Control in DBMS page





Saturday, April 16, 2016

Concurrency Anomalies - Lost Update Problem



Need for concurrency control, Concurrency Anomalies, Concurrent Execution Problems, Example for lost update problem, what does cause lost update problem in concurrent execution of transactions?


Lost Update Problem

Lost update problem occurs when two or more transactions are updating same data items simultaneously. The transaction (among the concurrent transactions) that commits at last (lately) will decide the final value of that particular data item.

Example:

To understand lost update problem, let us use the schedule 1 given in Table 2.
Let us assume that the initial value of data items A and B are 1000 and 1000 respectively. Transaction T1 transfers 50 from A to B. Transaction T2 withdraws 10% of amount from A. If T1 and T2 are executed in serial order then the final values will be as given in the Table 1;

If T1 then T2
If T2 then T1
Final values are,
A = 855
B = 1050
Final values are,
A = 850
B = 1050
Table 1: Final values of A and B if T1 and T2 are executed in serial order

Let us suppose that we go for concurrent execution of T1 and T2, ie., the instructions of both transactions are interleaved, for example, as given in the table 2. As given in the table 2, the execution goes as follows;

  • T1 reads A (current value of A = 1000) then it calculates the new value of A (new value of A = 950).

  • Now the control goes to T2 and T2 read A (current value of A = 1000). After that T2 calculates the new value of A as per its instruction (new value of A = 900).

  • Then again control is transferred to T1 and T1 writes new value of A as it has calculated by T1. That means, T1 writes 950 as the new value of A and then reads the current value of B as 1000.

  • Now, the control is transferred to T2 and T2 writes the new value of A as 900. Actually T2 overwrites the value that has been written by T1. That means T1 lost its update due to the action of T2.

  • T1 takes the control and calculates the new B value, ie., B = 1050.

The final value of A and B are 900 and 1050 respectively as produced by schedule 1, which is wrong. This is because, T2 overwrites a value which was written by T1.

Transaction T1
Transaction T2
A = 1000, B = 1000
read(A);
A := A – 50;



write(A);
read(B);


B := B + 50;
write(B);
commit;


read(A);
temp := A * 0.1;
A := A – temp;


write(A);
commit;
T1 read: A = 1000

T2 read: A = 1000


T1 write: A = 950
T1 read: B = 1000
T2 write: A = 900 (Overwrite)


T1 write: B = 1050
Table 1: Schedule 1
Discussion:


  • Overwriting an uncommitted data leads the database to an inconsistent state.

  • Lost update problem is caused due to Write-Write conflict between transactions.


***********************

Go to Transaction Management in DBMS home page

Go to Some keywords in DBMS - Need to know page
 
Go to Need for Concurrency Control in DBMS page

Featured Content

Multiple choice questions in Natural Language Processing Home

MCQ in Natural Language Processing, Quiz questions with answers in NLP, Top interview questions in NLP with answers Multiple Choice Que...

All time most popular contents

data recovery