This document discusses concurrency control and methods to ensure serializability when transactions execute concurrently in a database. It begins by describing three problems that can occur with concurrent transaction execution: lost updates, unrepeatable reads, and dirty reads. It then explains two methods for achieving serializability: multi-version concurrency control and timestamp ordering. Timestamp ordering assigns timestamps to transactions and data items and uses the timestamps to determine when transactions can read and write data items to prevent conflicts. The document also briefly mentions using concurrency control protocols that employ locking to serialize transaction access.

1. 1. Problems due to the Concurrent Execution
of Transactions
2. Methods for Serialisability
3. Concurrency Control

2. 1. Problems due to the Concurrent Execution of Transactions
◆ Introduction
▪ Concurrency control:
- The management of contention for data resources.
- Ensures that correct results for concurrent operations are
generated, while getting those results as quickly as possible.
- Each transaction does not interfere with another transaction with
one another in a way that produces incorrect results.
▪ Concurrent execution of transactions
- must be such that each transaction appears to execute in isolation.

3. 1. Problems due to the Concurrent Execution of Transactions
◆ Problems due to the Concurrent Execution of Transactions
▪ The lost update problem
▪ The incorrect summary or unrepeatable read problem
▪ The temporary update (dirty read) problem

4. 1. Problems due to the Concurrent Execution of Transactions
▪ The lost update problem
Two transactions accessing the same database item have their
operations interleaved in a way that makes the database item incorrect
Let x=4, y=8, n=2, m=3.
Item x has incorrect value because its update from t1 is “lost”
(overwritten)
T2 reads the value of x before t1 changes it in the database and hence
the updated database value resulting from t1 is lost.

5. 1. Problems due to the Concurrent Execution of Transactions
▪ The incorrect summary or unrepeatable read problem
One transaction is calculating an aggregate summary function on a
number of records while other transactions are updating some of these
records. The aggregate function may calculate some values before they
are updated and others after.
T2 reads x after n is subtracted and reads y before n is added, so a
wrong summary is the result.

6. 1. Problems due to the Concurrent Execution of Transactions
▪ The temporary update (dirty read) problem
One transaction updates a database item and then the transaction fails.
The updated item is accessed by another transaction before it is changed
back to its original value.
Transaction t1 fails and must change the value of x back to its old value
Meanwhile t2 has read the “temporary” incorrect value of x.

7. 2. Methods for Serialisability
▪ Multi-version concurrency control techniques
Keep the old values of a data item when that item is updated.
▪ Timestamp ordering
- Each transaction has a time-stamp.
- Transactions are serialized according to this time-stamp.
- older transactions abort and restart if they have a conflict with an
younger transaction.
- Each object has two time stamps rd and wr.
- times of the transactions which read (wrote) that object last.
- each object will have a list of tentative transaction times for pending
writes. Let tmin be the minimum of these tentative times.
The following actions are taken with each event:

8. 2. Methods for Serialisability
▪ Timestamp ordering
The following actions are taken with each event:
☞ Read: If the time-stamp of this read is smaller than wr, this transaction
is aborted. It is allowed to proceed if it’s time stamp is in
between wr and tmin. It is kept in a queue otherwise for some
other writes to commit.
☞ Write: Allowed to proceed only if it’s time stamp is greater than both
rd and wr. Then the write is marked tentative and put in the list.
☞ Abort: Aborted read has no effect. Aborted write is removed from the
tentative list and if a pending read reaches the head of the
queue, it is performed.
☞ Commit: A commit may not involve any pending read. If it has any
pending write then all preceding tentative writes aborted and
this transaction is committed.

9. 2. Methods for Serialisability
▪ Protocols
If protocols are followed by every transaction,
- It will ensure serialisability of all schedules in which the transactions
participate.
- They may use locking techniques of data items to prevent multiple
transactions from accessing items concurrently.