Scribd
Upload
94 views

ACID Properties of Transaction

Transactions must satisfy the ACID properties of atomicity, consistency, isolation, and durability to maintain database integrity. Lock-based concurrency control protocols use locking mechanisms like shared locks and exclusive locks to ensure serializable schedules and isolate transactions from each other. Schedules represent the order transactions access and modify data, and a schedule is serializable if it is equivalent to some serial schedule that processes transactions one at a time.

Uploaded by

चौधरीखड़क
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
94 views

ACID Properties of Transaction

Transactions must satisfy the ACID properties of atomicity, consistency, isolation, and durability to maintain database integrity. Lock-based concurrency control protocols use locking mechanisms like shared locks and exclusive locks to ensure serializable schedules and isolate transactions from each other. Schedules represent the order transactions access and modify data, and a schedule is serializable if it is equivalent to some serial schedule that processes transactions one at a time.

Uploaded by

चौधरीखड़क
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Desirable properties of Transaction

To maintain integrity of data, the database system must maintain some desirable properties of
transaction. These properties are known as ACID properties, the acronym derived from the
first letters of terms: Atomicity, consistency, Isolation and Durability.
ACID properties:
• Atomicity: A transaction is an atomic unit of processing; it is either performed in its
entirety or not performed at all.
• Consistency preservation: A correct execution of the transaction must take the
database from one consistent state to another.
• Isolation: A transaction should not make its updates visible to other transactions until it
is committed; this property, when enforced strictly, solves the temporary update
problem and makes cascading rollbacks of transactions unnecessary.
• Durability or permanency: Once a transaction changes the database and the changes
are committed, these changes must never be lost because of subsequent failure.

Model used for representing database modifications of a transaction:


read(A,x): assign value of database object A to variable x;
write(x,A): write value of variable x to database object A

Example of a Transaction T
read(A,x)
x : = x - 200
write(x,A)

read(B,y)
y : = y + 200
write(y,B)

Concurrency Control: Lock-Based Protocols


_ One way to ensure Serializability is to require that accesses to data objects must be done in a
mutually exclusive manner.
_ Allow transaction to access data object only if it is currently holding a lock on that object.
_ Serializability can be guaranteed using locks in a certain fashion

Types of locks that can be used in a transaction T:


_ slock(X): shared-lock (read-lock); no other transaction than
T can write data object X, but they can read X
_ xlock(X): exclusive-lock; T can read/write data object X; no
other transaction can read/write X, and
_ unlock(X): unlock data object X
Lock-Compatibility Matrix:
requested lock existing lock
slock (Read) Xlock(Write)
slock (Read) OK No
xlock (Write) No No

E.g., xlock(A) has to wait until all slock(A) have been released.

Using locks in a transaction (lock requirements, LR):


_ before each read(X) there is either a xlock(X) or a slock(X) and no unlock(X) in between
_ before each write(X) there is a xlock(X) and no unlock(X) in between
_ a slock(X) can be tightened using a xlock(X)
_ after a xlock(X) or a slock(X) sometime an unlock(X) must occur

But: \Simply setting locks/unlocks is not sufficient" replace each read(X) ! slock(X); read(X);
unlock(X), and write(X) ! xlock(X); write(X); unlock(X)

Schedules:
Schedules are sequences that indicate the chronological order in which instructions of
concurrent transactions are executed
 a schedule for a set of transactions must consist of all instructions of those transactions
 must preserve the order in which the instructions appear in each individual transaction.
Example Schedules: Schedule 1:
Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B. The following
is a serial schedule in which T1 is followed by T2.

T1 T2
read(A)
A := A-50
write(A)
read(B)
B:= B + 5
write(B)
read(A)
temp:=A*0.1
A := A-temp
write(A)
read(B)
B:= B + temp
write(B
Example Schedule: Schedule2
Let T1 and T2 be the transactions defined previously. The following schedule is not a serial
schedule, but it is equivalent to a serial schedule.

T1 T2
read(A)
A := A-50
write(A)

read(A)
temp:=A*0.1
A := A-temp
write(A)

read(B)
B:= B + 5
write(B)

read(B)
B:= B + temp
write(B)
In both Schedule 1 and 3, the sum A + B is preserved.

Example Schedules: Schedule 3


The following concurrent schedule does not preserve the value of
the sum A + B.
T1 T2
read(A)
A := A-50
read(A)
temp:=A*0.1
A := A-temp
write(A)
read(B)

write(A)
read(B)
B:= B + 5
write(B)
B:= B + temp
write(B)

Serializability
Each transaction preserves database consistency. Thus, serial execution of a set of transactions
preserves database consistency.
A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule. Different
forms of schedule equivalence give rise to the notions of:
1. conflict serializability
2. view serializability

You might also like