Transactions and Concurrency CSD305 Advanced Databases

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

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

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

Buried Update problem CSD305 Advanced Databases

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

Concurrent vs. serialized transactions CSD305 Advanced Databases

The transaction concept CSD305 Advanced Databases

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

Dirty Read CSD305 Advanced Databases

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

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

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

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

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

Serializability CSD305 Advanced Databases

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

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

Two-phase locking CSD305 Advanced Databases

The lock table CSD305 Advanced Databases

Example effect of locking regime CSD305 Advanced Databases

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

Deadlock CSD305 Advanced Databases

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

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

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

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.

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

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

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.

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.

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

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