TRANSACTION MANAGEMENT
R.SARAVANAKUAMR.
S.NAVEEN.
Transactions
•A transaction is a sequence of operations thatperform a single logical task.
•The database must be in a consistent state beforeand after a transaction but may becomeinconsistent during execution.
•Transaction management ensures that thedatabase can be restored to a consistent state ifsomething goes wrong during the transaction.
Transaction Concepts
Structure of a Transaction
Begin transaction
Read input message
Perform processing
against database
If successful
send output message(s)
and COMMIT
else
send error message
and ROLLBACK
End transaction
Transfer Rs.500 from savings accountto 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-Amt
End transaction
ACID Properties of a Transaction
•Atomicity
–either all or none of the operations of a transaction areperformed.
•Consistency
–Data Base is in a consistent state before and after aexecuting a transaction (may be inconsistent duringexecution).
•Isolation
–Transactions are isolated from one another.
•Durability
–Once transaction commits, the changes it has made to DataBase persist, even if system fails.
Transaction access data using twooperation
•Read(x) – Which transfers the data item x from the databaseto local buffer belonging to the transaction that executed theread operation.
•Write (x) – Which transfers the data item x from the localbuffer to the transaction that executed the write back to thedatabase
•If the database operations in a transaction do not update thedatabase but only retrieve data , the transaction is called aread-only transaction.
Transaction states
Active
Partially
Committed
Failed
Committed
Aborted
Transaction States
•Active: Initial state; when the transaction is executing
•Partially Committed: When the last statement has finishedexecution
•Failed: On discovery that normal execution can no longerproceed
•Aborted: After the rollback is performed from a failedtransaction
•Committed: After successful completion
•Terminated: Aborted
Shadow Copy
A transaction that wants to update the database first create acomplete copy of the database . All updates are done on thenew database copy, leaving the original copy.
If at any point the transaction has to be aborted , the systemmerely deletes the new copy. The old copy of the database hasnot been affected.
Concurrent Executions
Improve throughput & Resource Utilization:
Throughput :The Number of transaction Executed in a givenamount of time.
Resource Utilization:
The processor and Disk utilization
Reduced Waiting time:
The average time for a transaction to be completed after ithas 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 thenet effect should be as though the transactions were executed insome serial order.
Good schedule
T1 T2
read(A)
A := A - 50
write(A)read(A)
temp = A *.1
A := A - temp
write(A)
read(B)
B := B + 50
write(B)
read(B)
B := B + temp
write(B)
Bad schedule
T1T2
read(A)
A := A - 50
read(A)
temp = A *.1
A := A - temp
write(A)
read(B)
write(A)
read(B)
B := B + 50
write(B)
B := B + temp
write(B)
Conflict Serializability
•Let instructions I and J belonging to transactions T1and T2 be executed consecutively by the DBMS.
1.I and J can be swapped in their execution order if I andJ refer to different data elements
2.I and J can be swapped in their execution order if I andJ refer to the same data element and both perform aread operation only.
3.I and J are said to conflict if I and J belong to differenttransactions and at least one of them is a writeoperation
Conflict Serializability
•If a schedule S can be transformed to anotherS’ by swapping non conflicting instructions,then S and S’ are said to be conflict equivalent.
•A schedule S is said to be conflict serializable ifit 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 notconflict and the order is not important.
2.If two transaction either read or write completely separatedata objects then they don’t conflict and the order is notimportant.
3.If one transaction writes a data object and another eitherreads or writes the same data objects then the order ofexecution is important.
4.Two actions on the same data object conflict if at least oneof them is a write.
T1
T2
Read A
Write A
Read A
Read B
Write A
Write B
Read B
Write B
T1
T2
Read A
Write A
Read B
Write B
T1
T2
Read B
Write B
Read A
Write 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 equivalentschedule if
•For each data item Q, if a transaction Ti readsthe initial value of Q in S, then it should readthe 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 thesame in S’
•The same transaction that performs the finalwrite(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 Q
Write Q
Write Q
Write Q
View Serializability
•Every conflict serializable schedule is also viewserializable; however some view serializableschedules are not conflict serializable
•Example in previous slide
•A schedule that is view serializable but notconflict serializable is characterized by blindwrites.
Serializable Executions
•An interleaved execution of some transactions iscorrect if it produces the same result as some serialexecution 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 mutuallyexclusive manner.
•While one transaction accesses a data item, noother transaction should modify it.
•Locking ensures that a data item can be updatedonly if the transaction holds a lock on the dataitem.
•Two types of lock:
–Shared locks-can read data item, but can’t write.
–Exclusive locks-can performed both read and writeoperation.
Shared locks
•If a transaction holds a shared lock (S-lock) onan object, other transactions can also request
S-locks.
•However, a transaction cannot acquire anexclusive lock on the object.
•If a transaction has the only shared lock on anobject, it can be promoted to an exclusive lock.
Recoverability->Rollback
•Recoverable schedule
A recoverable schedule is one where, for each pairof transactions Ti and Tj such that Tj reads a data itempreviously written by Ti, the commit operation of Tiappears before the commit operation of Tj. Mostdatabase system require that all schedules berecoverable.
•Cascadeless schedules
A single transaction failure leads to a series oftransaction rollbacks, is called cascading rollback.
Concurrency control manager(1)Request (2)Grant
T1 T2 CCM
lock-X(A) Grant(X,A)
Read(A)
A := A – 50
Write(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) onan object, no other transaction can acquire a lockon 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, eitherthrough COMMIT or ROLLBACK
Locking protocols
T1 T2
lock-X(A)
read(A)
A := A - 50
write(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 becauseT1 has an X-lock on A.
Deadlocks
•In a database, a deadlock is a situation inwhich two or more transactions are waitingfor one another to give up locks.
•X-locks may lead to deadlocks.
•This arises when two transactions aremutually excluded from accessing the nextrecord required to computer their transaction.
Example of Deadlock
T1 T2
lock-X(B)
update B
lock-X(A)
update A
request lock(A)
wait for T2 to
release lock on A
request lock(B)
waiting for T1 to
release 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 indead deadlock state”
A transaction must lock all the data items it needs beforeexecution begins.
Data-item utilization may be slow.
Ordering
If a transaction requires access to two records, make surethat 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 usingtimestamp are:
1.Wait die
-The wait-die scheme is nonpreemptiontechnique.
2.Wound wait
-The wait-die scheme is preemptivetechnique.
Timeout based schemes
In this approach, a transaction that has requested alock waits for at most a specified amount of time.
Detection and Recovery
•“This approach tries to recover from deadlock ifsystem enters in deadlock state”
•Periodically, let DBMS check to determine if linewaiting for resource exceeds some limit.
•Use graph manipulation to detect deadlocks:
–Draw arrow from transaction to record beingsought, and from record to transaction using it.
–If graph has cycles, then we have deadlock.
•If deadlock detected, cancel one transaction andadvance other.