1. Transaction Management and Concurrency Control
Advanced Database
Dr. AlaaEddin Almabhouh

2. Learning outcomes At the end of this chapter, you will be able to:
Define the terms: Transaction, Concurrency control, ACID, timestamp
Explain briefly the properties of transaction
Discuss the problems happen during the time concurrent access.
Discuss the various database locking techniques.

3. Transaction ? Transactions a transaction is a logical unit of work
an action or series of actions which access or change the contents of a database

4. Example BEGIN TRANSACTION;
INSERT ({S#:’S5’, P#:’P1’, QTY:1000}) INTO SP;
IF any error occurred THEN GO TO UNDO;
UPDATE P WHERE P# # ‘P1’ TOTQTY:=TOTQTY ;
COMMIT TRANSACTION;
GO TO FINISH;
UNDO:
ROLLBACK TRANSACTION;
FINISH:
RETURN;

5. Transaction
The previous example (a logical unit of work) involves two updates
The database can be deemed to be inconsistent during that transaction
Both updates need to be executed or the database will be left in an inconsistent state
A systems that supports Transaction Processing enables successful completion of transactions
the entire transaction executes or is totally cancelled

6. ACID Properties
ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably.
In the context of databases, a single logical operation on the data is called a transaction.
For example, a transfer of funds from one bank account to another, even though that might involve multiple changes (such as debiting one account and crediting another), is a single transaction.

7. Transaction Properties
ATOMICITY
‘all or nothing’. A transaction is an indivisible unit
CONSISTENCY
Consistency is a very general term that demands the data meets all validation rules that the overall application expects
ISOLATION
To demonstrate isolation, we assume two transactions execute at the same time, each attempting to modify the same data. One of the two must wait until the other completes in order to maintain isolation.
DURABILITY
The effects of a successfully completed transaction must persist and not be lost because of subsequent failure.
To satisfy the durability constraint, the database system must ensure the success message is delayed until the transaction is finalized.

8. Transaction manager The transaction manager provides atomicity
COMMIT TRANSACTION (Commit)
signals successful end of transaction
the database should be (or is) in a consistent state
all the updates can be made permanent
ROLLBACK TRANSACTION (Rollback)
signals unsuccessful end of transaction
all updates made by the logical unit of work must be undone

9. Transaction logging Transactions are tracked by using logs
Transaction records
transaction ID
type of log (start of transaction, insert, update..)
identifier of the data item affected
before image (value before change)
after image (value after change)
log management information (pointers)
Logs can also be used for performance monitoring and auditing

10. Transaction logging

11. Systems Recovery System failure
the contents of main memory are lost
the exact status of transactions in progress is unknown
these transactions have to be UNDONE (rolled back) on system start up
transactions that do complete but do not manage to have the updates transferred to disk must be REDONE (rolled forward)
Check points determine whether a rollback or roll forward is required
Checkpoint
the point of synchronisation between the database & transaction log file. All buffers are force written to secondary storage

12. Recovery - transaction categories
Time tc tf T r a n s c t I o T1 T2 T3 T4 T5
At restart time, therefore, the system first goes through the following procedure in order to identify all transactions of types T2–T5:
Start with two lists of transactions, the UNDO list and the REDO list. Set the UNDO list equal to the list of all transactions given in the most recent checkpoint record; set the REDO list to empty.
Search forward through the log, starting from the checkpoint record.
If a BEGIN TRANSACTION log entry is found for transaction T, add T to the UNDO list.
If a COMMIT log entry is found for transaction T, move T from the UNDO list to the REDO list.
When the end of the log is reached, the UNDO and REDO lists identify, respectively, transactions of types T3 and T5 and transactions of types T2 and T4.
The system now works backward through the log, undoing the transactions in the UNDO list; then it works forward again, redoing the transactions in the REDO list.
Note: Restoring the database to a consistent state by undoing work is sometimes called backward recovery. Similarly, restoring it to a consistent state by redoing work is sometimes called forward recovery.
Finally, when all such recovery activity is complete, then (and only then) the system is ready to accept new work.
Checkpoint
(time tc)
System failure
(time tf)

13. Transaction recovery
Start with 2 lists of transactions, the UNDO list and the REDO list
set the UNDO list equal to the list of all transactions in the most recent checkpoint
set the REDO list to empty
Search forward through the log, starting from the checkpoint record
If a BEGIN TRANSACTION entry is found for T, add T to the UNDO list
If a COMMIT log entry is found for transaction T, move T from the UNDO list to the REDO list
When the end of the log is reached, the 2 lists contain relevant transactions

14. Concurrency Control

15. Concurrency Control
The process of managing simultaneous operations on the database without having them interfere with one another
Enables multi-user and multi-program access without compromising database integrity
Main features of a concurrency control protocol
shared/exclusive locking
granularity
lock acquisition
lock release

16. The lost update problem
Transaction A time Transaction B
RETRIEVE p t -
- t2 RETRIEVE p
UPDATE p t
- t4 UPDATE p

17. The lost update problem
Time Program X Program 2 40
t read x
t read x
t update x
x:=x
write x (commit) 60
t update x
60 x:=x+30
70 write x (commit)
Every thing is ok until we reach t4
The update in t4 will take the value of x in t2
That means x = x + 30  x = = 70
But the value of x has been updated by t3 in program1
That means x = x + 30  x = = 90
this is the true value 90 not 70

18. Uncommitted dependency
Arises if one transaction is allowed to retrieve or update a tuple that has been updated by another transaction but not yet committed
Transaction A time Transaction B
t1 UPDATE p
RETRIEVE p t
- t3 ROLLBACK
Transaction A becomes dependent on an uncommitted change at t2

19. Uncommitted dependency
Time Program 1 Program 2 bal
t1 begin 100
t2 read(bal) 100
t3 bal:=bal
t4 begin write(bal)
t5 read(bal) : 200
t6 bal:=bal-10 rollback 100
t7 write(bal)
t8 commit
The problem here is that at t4 we read the bal updated on t3
But after that at t6 the program 2 rollback that means the update
Has been removed from 200 to 100 go to t1 (rollback all the transactions). but program1 until now is working
on 200 value

20. Locking Concurrency problems can be solved by locking
A procedure to control concurrent access to data. When one transaction is accessing the database, a lock may deny access to other transactions
Exclusive locks (X locks)
if a transaction holds an exclusive lock on P then a request from some other transaction on P will be denied
Shared locks (S locks)
if a transaction holds a shared lock on P then a request from other transactions for an X lock will be denied
a request from other transactions for a S lock on P will be granted

21. Locking S X true false False Tj Ti
S , S true because we allow two shared locks on the tuple
Locks must be held for a duration of access

22. A data access protocol
A transaction that wishes to retrieve a tuple (row) must acquire an S lock on that tuple
A transaction that wishes to update a tuple must acquire an X lock on that tuple
A transaction will go into a wait state if a lock is denied
X and S locks are normally held until the end of a commit or rollback is issued
Note: Transaction requests for tuple locks are normally implicit; a "tuple retrieve" request is an implicit request for an S lock, and a "tuple update" request is an implicit request for an X lock, on the relevant tuple. Also, of course (as always), we take the term "update" to include INSERTs and DELETEs as well as UPDATEs per se, but the rules requires some minor refinement to take care of INSERTs and DELETEs. We omit the details here.

23. The lost update problem
Transaction A time Transaction B
RETRIEVE p t1
(acquire S lock on P) -
- t2 RETRIEVE p
- (acquire S lock on P
UPDATE p t
(acquire X lock on P)
wait t4 UPDATE p
wait (acquire S lock on P)
wait wait
Fig is a modified version of Fig , showing what would happen to the interleaved execution of that figure under the locking protocol described in Section Transaction A's UPDATE at time t3 is not accepted, because it is an implicit request for an X lock on t, and such a request conflicts with the S lock already held by transaction B; so A goes into a wait state. For analogous reasons, B goes into a wait state at time t4. Now both transactions are unable to proceed, so there is no question of any update being lost. Locking thus solves the lost update problem by reducing it to another problem!—but at least it does solve the original problem. The new problem is called deadlock. It is discussed in Section 15.5.

24. Uncommitted dependency
Transaction A time Transaction B
t1 UPDATE p
- (acquire X lock on P)
RETRIEVE p t
(request S lock on P)
wait t3 COMMIT/ROLLBACK
wait (release X lock on P)
wait
resume: RETRIEVE P t4
(acquire S lock on P)

25. Q & A
Slide 81 (of 82)