TRANSACTION MANAGEMENT

R.SARAVANAKUAMR. S.NAVEEN.

Transactions• A transaction is a sequence of operations that

perform a single logical task.

• The database must be in a consistent state before and after a transaction but may become inconsistent during execution.

• Transaction management ensures that the database can be restored to a consistent state if something goes wrong during the transaction.

Transaction ConceptsStructure of a Transaction

Begin transaction Read input message Perform processing

against database If successful

send output message(s)and COMMIT

elsesend error messageand ROLLBACK

End transaction

Transfer Rs.500 from savings account to checking account.

Begin transaction Read Sav_Amt Sav_Amt := Sav-Amt - 500 Write Sav_Amt Read Chk_Amt Chk_Amt := Chk_Amt + 500 Write Chk-AmtEnd transaction

ACID Properties of a Transaction• Atomicity– either all or none of the operations of a transaction are

performed.• Consistency– Data Base is in a consistent state before and after a

executing a transaction (may be inconsistent during execution).

• Isolation– Transactions are isolated from one another.

• Durability– Once transaction commits, the changes it has made to Data

Base persist, even if system fails.

Transaction access data using two operation

• Read(x) – Which transfers the data item x from the database to local buffer belonging to the transaction that executed the read operation.

• Write (x) – Which transfers the data item x from the local buffer to the transaction that executed the write back to the database

• If the database operations in a transaction do not update the database but only retrieve data , the transaction is called a read-only transaction.

Transaction states

Active

PartiallyCommitted

Failed

Committed

Aborted

Transaction States• Active: Initial state; when the transaction is executing

• Partially Committed: When the last statement has finished execution

• Failed: On discovery that normal execution can no longer proceed

• Aborted: After the rollback is performed from a failed transaction

• Committed: After successful completion

• Terminated: Aborted

Shadow Copy

A transaction that wants to update the database first create a complete copy of the database . All updates are done on the new database copy, leaving the original copy.

If at any point the transaction has to be aborted , the system merely deletes the new copy. The old copy of the database has not been affected.

Concurrent Executions Improve throughput & Resource Utilization: Throughput :

The Number of transaction Executed in a given amount of time.

Resource Utilization:

The processor and Disk utilization

Reduced Waiting time: The average time for a transaction to be completed after

it has been submitted.

Serializability

Transaction T1:

read (A) A = A – 50; write (A) read (B) B = B + 50; write (B)

Transaction T2:

read (A) t = A * 0.1;

A = A – t; write (A) read (B)

B = B + t; write (B)

On executing a set of concurrent transactions on a database the net effect should be as though the transactions were executed in some serial order.

Good scheduleT1 T2

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

read(A)temp = A *.1A := A - tempwrite(A)

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

read(B)B := B + tempwrite(B)

Bad scheduleT1 T2read(A)A := A - 50

read(A)temp = A *.1A := A - tempwrite(A)read(B)

write(A)read(B)B := B + 50write(B)

B := B + tempwrite(B)

Conflict Serializability• Let instructions I and J belonging to transactions T1

and T2 be executed consecutively by the DBMS.

1. I and J can be swapped in their execution order if I and J refer to different data elements

2. I and J can be swapped in their execution order if I and J refer to the same data element and both perform a read operation only.

3. I and J are said to conflict if I and J belong to different transactions and at least one of them is a write operation

Conflict Serializability

• If a schedule S can be transformed to another S’ by swapping non conflicting instructions, then S and S’ are said to be conflict equivalent.

• A schedule S is said to be conflict serializable if it is conflict equivalent to some serial schedule.

• Ii=Read(Q), Ij=Read(Q)• Ii=Read(Q),Ii=Write(Q)

Rules to define conflict operation 1. If two transaction just read a data object then they do not

conflict and the order is not important.

2. If two transaction either read or write completely separate data objects then they don’t conflict and the order is not important.

3. If one transaction writes a data object and another either reads or writes the same data objects then the order of execution is important.

4. Two actions on the same data object conflict if at least one of them is a write.

T1 T2

Read AWrite A

Read A

Read B

Write A

Write B

Read BWrite B

T1 T2

Read AWrite A

Read BWrite B

T1 T2

Read BWrite B

Read AWrite A

T1 T2

X=x+5

X=x*2

Y=Y-100

Y=Y*5

T1 T2

X=x+5

X=x*2

Y=Y-100

Y=Y*5

View Serializability

If S is a schedule, then S’ is a view equivalent schedule if

• For each data item Q, if a transaction Ti reads the initial value of Q in S, then it should read the initial value in S’ also

• In schedule S, for each data item Q, if write(Q) of Tj precedes read(Q) of Ti, it should be the same in S’

• The same transaction that performs the final write(Q) in S, should perform it in S’.

View Serializability

A view equivalent schedule: T3: Read(Q) T4: Write(Q)T3: Write(Q) T5: Write(Q)

T3 T4 T5

Read QWrite Q

Write QWrite Q

View Serializability

• Every conflict serializable schedule is also view serializable; however some view serializable schedules are not conflict serializable

• Example in previous slide

• A schedule that is view serializable but not conflict serializable is characterized by blind writes.

Serializable Executions• An interleaved execution of some transactions is

correct if it produces the same result as some serial execution of the transactions.

• Such an execution is called serializable.

• A concurrency control scheme must prevent non-serializable execution from occurring.

• One possibility is locking.

Locks• Data items can be accessed in a mutually exclusive

manner.• While one transaction accesses a data item, no

other transaction should modify it.• Locking ensures that a data item can be updated

only if the transaction holds a lock on the data item.

• Two types of lock:– Shared locks-can read data item, but can’t write.– Exclusive locks-can performed both read and write

operation.

Shared locks• If a transaction holds a shared lock (S-lock) on

an object, other transactions can also request S-locks.

• However, a transaction cannot acquire an exclusive lock on the object.

• If a transaction has the only shared lock on an object, it can be promoted to an exclusive lock.

Recoverability->Rollback• Recoverable schedule A recoverable schedule is one where, for each pair

of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operation of Tj. Most database system require that all schedules be recoverable.

• Cascadeless schedules A single transaction failure leads to a series of

transaction rollbacks, is called cascading rollback.

Concurrency control manager(1)Request (2)Grant

T1 T2 CCMlock-X(A) Grant(X,A)Read(A) A := A – 50Write(B)Unlock(A) Lock-x(B) lock S(A) Grant(X,B)Read(B) Read(A)B:=B+50; Display(A) Grant(S,A)Write(B) unlock(A)Unlock(B)

Exclusive Locks• If a transaction holds an exclusive lock (X-lock) on

an object, no other transaction can acquire a lock on the object, or access it.

• To update a record R through some transaction T– T must obtain an X-lock on R– The X-lock must be retained until the end of T, either

through COMMIT or ROLLBACK

Locking protocols T1 T2lock-X(A)read(A)A := A - 50write(A) unlock(A lock-X(A)

read(A) temp = A *.1 A := A - temp write(A) unlock(A)

X-locks Block Bad Interleaving

T1 T2

lock-X(A)read(A)A := A - 50

read(A)

• The read(A) of T2 cannot be executed because T1 has an X-lock on A.

Deadlocks• In a database, a deadlock is a situation in

which two or more transactions are waiting for one another to give up locks.

• X-locks may lead to deadlocks.

• This arises when two transactions are mutually excluded from accessing the next record required to computer their transaction.

Example of Deadlock T1 T2lock-X(B)update B

lock-X(A) update A

request lock(A)wait for T2 torelease lock on A

request lock(B)waiting for T1 torelease lock on B

Deadlocks• Deadlocks can be overcome by:

1 ) Prevention 2) Detection and Recovery 1 ) Prevention

“This approach ensures that system will never enter in dead deadlock state”

A transaction must lock all the data items it needs before execution begins.

Data-item utilization may be slow. Ordering If a transaction requires access to two records, make sure

that they are always accessed in the same order. In our case, always access A before B. May slow down operations considerably

Two different deadlock prevention schemes using timestamp are:

1.Wait die -The wait-die scheme is nonpreemption

technique. 2.Wound wait -The wait-die scheme is preemptive

technique. Timeout based schemes In this approach, a transaction that has requested a

lock waits for at most a specified amount of time.

Detection and Recovery • “This approach tries to recover from deadlock if

system enters in deadlock state”• Periodically, let DBMS check to determine if line

waiting for resource exceeds some limit.• Use graph manipulation to detect deadlocks:– Draw arrow from transaction to record being

sought, and from record to transaction using it.– If graph has cycles, then we have deadlock.

• If deadlock detected, cancel one transaction and advance other.