1. Transactions and Concurrency
CSD305 Advanced Databases

2. Agenda Problems of concurrent access The transaction concept
The ACID properties
A simple locking scheme
Isolation levels
Locking granularity
An optimistic approach
Concurrency in MS SQL Server
Designing for concurrency
CSD305 Advanced Databases

3. Problems of concurrent access
A range of problems can arise when multiple users are updating and reading a shared database.
There are well known categories of problems known as
Buried Update
Dirty Read
Unrepeatable Read
Phantoms
CSD305 Advanced Databases

4. Buried Update
This problem arises when the effect of one user's action overwrites (buries) the effect of another
The following scenario demonstrates a buried update in the context of a flight booking system.
CSD305 Advanced Databases

5. Buried Update problem
CSD305 Advanced Databases

6. Analysis of the buried update problem
The problem arises because two units of work (transactions), operating concurrently, interfere with each other's activity.
The problem would be solved if the two transactions were to run in series rather than concurrently.
CSD305 Advanced Databases

7. Concurrent vs. serialized transactions
CSD305 Advanced Databases

8. The transaction concept
CSD305 Advanced Databases

9. Other concurrency problems
We have established that buried update is a serious concurrency problem
Other problems are:
Dirty Read (uncommitted dependency)
Unrepeatable Read (inconsistent analysis)
Phantoms we'll look at each in turn
CSD305 Advanced Databases

10. Dirty Read
CSD305 Advanced Databases

11. Unrepeatable read CSD305 Advanced Databases
If someone performs an update or delete to any of the rows read earlier

12. Phantoms CSD305 Advanced Databases
If Insert new row within range returned earlier for particular query new results will be returned for that query

13. Summary of the problems
Dirty read
A transaction reads data written by another transaction, but not yet committed
Unrepeatable read
A transaction reads data it has previously read and finds that it has been updated or deleted
Phantom read
A transaction reissues a select statement and discovers new data has been inserted that meets the select criteria
CSD305 Advanced Databases

14. The ACID properties
All the problems we have examined can be solved by making our transactions:
Atomic
Indivisible, all or nothing
Consistent
Take the database from one consistent state to another
Isolated
No mutual interference between transactions
Durable
Once completed, their effects persist
CSD305 Advanced Databases

15. Isolation and serializability
All of the concurrent access problems outlined so far can be avoided if
The ACID properties are maintained
Full isolation between transactions is maintained
The effect of full isolation is that, although transactions are being processed in parallel, they give the same effects as if they were processed in series i.e. they are serializable
CSD305 Advanced Databases

16. Serializability
CSD305 Advanced Databases

17. A pessimistic approach to concurrency
The pessimist expects things to go wrong
Therefore the pessimistic approach to concurrency involves avoiding concurrency problems
Problems are avoided through the use of locking
CSD305 Advanced Databases

18. A simple locking regime
Before a transaction reads a row, it must gain a READ lock on that row
Before a transaction updates a row, it must gain a WRITE lock on that row
At any moment in time any given row can have at most
One WRITE lock OR
Many READ locks
If a transaction has the only READ lock on a row, the lock can be promoted to a WRITE lock
CSD305 Advanced Databases

19. Two-phase locking
CSD305 Advanced Databases

20. The lock table
CSD305 Advanced Databases

21. Example effect of locking regime
CSD305 Advanced Databases

22. Hanging transactions and timeouts
When a transaction requests a lock that is unavailable it has to wait
From the user’s perspective the transaction appears to “hang”
A “timeout” limit can be set so that a transaction backs out (rollback) if it has to wait too long
The transaction can be re-tried later on (in the expectation that locks have been released)
CSD305 Advanced Databases

23. Deadlock
CSD305 Advanced Databases

24. Compromising on isolation
Strict isolation ensures data integrity and that transactions see consistent views of the data.
However, strict isolation reduces the potential for parallel processing of transactions
Therefore, most DBMSs provide facilities to specify ISOLATION LEVELS for transactions
These should be chosen to provide appropriate levels of isolation for each type of transaction
CSD305 Advanced Databases

25. Setting Isolation Levels
SQL provides four levels of isolation
Serializable (highest)
Repeatable read – phantoms allowed
Read committed – nonrepeatable read also allowed
Read uncommited (lowest) – dirty read also allowed Example
CSD305 Advanced Databases
SET TRANSACTION ISOLATION LEVEL     READ COMMITTED
This is the default in SQL Server 2008

26. Locking granularity Locking is a resource-consuming activity
Row-level locking can result in large lock tables and system throughput can suffer
Locking coarser granules (e.g. tables) of data will reduce the size of lock tables and thus improve throughput
However coarser granules can also mean reduced concurrency
MS SQL Server 2008 can lock:
rows,
pages,
keys,
ranges of keys,
indexes,
tables, or
databases
CSD305 Advanced Databases

27. Dynamic locking granularity
CSD305 Advanced Databases
Lock granularity minimum amount of data that is locked as part of a query or update to provide complete isolation and serialization for the transaction.
The Lock Manager needs to balance the concurrent access versus the overhead of maintaining a large number of lower-level locks.
For example, the smaller the lock size, the greater the number of concurrent users, but the greater the overhead in maintaining those locks.
The greater the lock size, less overhead that is required to manage the locks, but concurrency is less.

28. An optimistic approach to concurrency
The optimist expects that things will not go wrong
Therefore the optimistic approach to concurrency control is to allow things to go wrong – but put them right when they do!
Principles
users do not lock data when they read it.
When data is updated, the system checks to see if another user changed the data after it was read.
If another user updated the data, an error is raised and the transaction is rolled back.
CSD305 Advanced Databases

29. Pessimistic vs. Optimistic
In general terms
Optimistic concurrency control works best when there is relatively little contention
Pessimistic concurrency control works best when there is a relatively high level of contention
CSD305 Advanced Databases

30. Concurrency in MS SQL Server
SQL Server 2008 provides a wide range of concurrency options, both pessimistic and optimistic
The options can be controlled from SQL by
Setting transaction isolation levels for a connection
Setting concurrency options on cursors
See the SQL Server 2008 documentation for details
CSD305 Advanced Databases
a cursor that makes a temporary copy of the data to be used by the cursor. All requests to the cursor are answered from this temporary table in tempdb; therefore, modifications made to base tables are not reflected in the data returned by fetches made to this cursor, and this cursor does not allow modifications.

31. Investigating the lock table in SQL Server
CSD305 Advanced Databases
SPID Identifies the system process ID
Shared (S)
Used for read operations that do not change or update data, such as a SELECT statement
Shared Locks
Shared (S) locks allow concurrent transactions to read (SELECT) a resource under pessimistic concurrency control. No other transactions can modify the data while shared (S) locks exist on the resource. Shared (S) locks on a resource are released as soon as the read operation completes, unless the transaction isolation level is set to repeatable read or higher, or a locking hint is used to retain the shared (S) locks for the duration of the transaction.
Intent
Used to establish a lock hierarchy. The types of intent locks are: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX).
Intent Locks
The Database Engine uses intent locks to protect placing a shared (S) lock or exclusive (X) lock on a resource lower in the lock hierarchy. Intent locks are named intent locks because they are acquired before a lock at the lower level, and therefore signal intent to place locks at a lower level.
Intent locks serve two purposes:
To prevent other transactions from modifying the higher-level resource in a way that would invalidate the lock at the lower level.
To improve the efficiency of the Database Engine in detecting lock conflicts at the higher level of granularity.

32. Designing for concurrency
Concurrency is a complex issue, but the following general principles should be considered
Keep transactions short
So that resources are not locked for long periods
Don’t wait for user input mid-transaction
Because locks could be held for long periods
Use the lowest isolation level that meets your transactions integrity needs
To increase concurrency
CSD305 Advanced Databases

33. Summary A range of problems arise from concurrent database activity
Database Management Systems provide a set of facilities to address these problems
The database administrator needs a good understanding of these facilities to ensure optimal performance of a multi-user system.
CSD305 Advanced Databases