Write-Read conflict : Reading uncommitted data

In computer science, in the field of databases, Write-Read Conflict, also known as reading uncommitted data, is a computational anomaly associated with interleaved execution of transactions.

Given a schedule D

<math>D = \begin{bmatrix}

T1 & T2 \\ R(A) & \\ W(A) & \\

 & R(A) \\
 & W(A)\\
 & R(B) \\
 & W(B) \\
 & Com. \\

R(B) & \\ W(B) & \\ Com. & \end{bmatrix}</math>

T2 could read a database object A, modified by T1 which hasn't committed. This is a dirty read.

T1 may write some value into A which makes the database inconsistent. It is possible that interleaved execution can expose this inconsistency and lead to inconsistent final database state, violating ACID rules.

Strict 2PL, overcomes this inconsistency by locking T2 out from A. Unfortunately, deadlocks is something Strict 2PL doesn't overcome as well.

		Write-Read conflict : Reading uncommitted data
		In computer science, in the field of databases, Write-Read Conflict, also known as reading uncommitted data, is a computational anomaly associated with interleaved execution of transactions. Given a schedule D <math>D = \begin{bmatrix} T1 & T2 \\ R(A) & \\ W(A) & \\ & R(A) \\ & W(A)\\ & R(B) \\ & W(B) \\ & Com. \\ R(B) & \\ W(B) & \\ Com. & \end{bmatrix}</math> T2 could read a database object A, modified by T1 which hasn't committed. This is a dirty read. T1 may write some value into A which makes the database inconsistent. It is possible that interleaved execution can expose this inconsistency and lead to inconsistent final database state, violating ACID rules. Strict 2PL, overcomes this inconsistency by locking T2 out from A. Unfortunately, deadlocks is something Strict 2PL doesn't overcome as well.
Put this code on your site