concurrent transactions(what is concurency transaction)

CHAPTER 4: CONCURRENT TRANSACTIONS

All DBMS allow concurrent transaction Allow multiple transactions to be executed at once.Transaction could be executed serially one after the other or be interleaved(switch back and forth between transaction

More than one transaction runnning simultaneously Improves efficiency Allows for multi-users in a single system

Problems of Transactions Concurrency• Three problems are

1. The lost update problem2. The temporary update (dirty read) problem3. Incorrect summary problem

1. The Lost Update ProblemTwo transactions accessing the same database item have their operations interleaved in a way that makes the database item incorrect.

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

Solution to Lost Update Use of Locks Example

o Lost Update with no locks

of 10

o Lost update with locks (the lock manager denies or grants locks)

Locks and their flavorso exclusive (or write-) lockso shared (or read-) lockso <and more ... >

Compatibility matrix – used in assigning locks

o transactions request locks (or upgrades)o lock manager grants or blocks requestso transactions release lockso lock manager updates lock-table

2. The Incorrect Summary or Inconsistent Analysis or Unrepeatable Read Problem One transaction is calculating an aggregate summary function on anumber 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.

=

of 10

T2 reads X after N is subtracted and reads Y before N is added, so a wrong summary is the result.

Solution to Inconsistent Analysis Locks are not enough Example

o Without locks

o With locks

General solution - Protocol(s):

o Most popular protocol: 2 Phase Locking (2PL) X-lock version: transactions issue no lock requests, after the first ‘unlock’ THEOREM: if all transactions obey 2PL -> all schedules are serializable transactions issue no lock/upgrade request, after the first

unlock/downgrade In general: ‘growing’ and ‘shrinking’ phase

o 2PL Featureso limits concurrencyo may lead to deadlockso strict 2PL (a.k.a. 2PLC): keep locks until ‘commit’

avoids ‘dirty reads’ etc but limits concurrency even more (and still may lead to deadlocks)

of 10

3. The Uncommited Dependency or Temporary Update (Dirty Read) Problem

o 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.

Concurrency Control TechniquesA number of techniques are used for controlling the concurrent execution of transactions:

1. Locking techniques2. Optimistic techniques

a. Time stampingb. Validation

Lock-based protocol Locking technique One way to ensure serializability is to require that access to data object must be done in a mutually exclusive manner ie allow transaction to access data object only if it is currently holding a lock on that object . A lock is avariable associated with a data item in the database generally there isz a lock for each item in the database .A lock describe the status of the data item with respect to possible operations that can be applied to that item.it is used for synchronizing the access by concurrent transaction to the data items .A transaction locks an object before using it.when an object is locked by another transaction the requesting transaction must wait.

Locking Techniques A lock is a variable associated with a data item in the database. Generally there is a

lock for each data item in the database. A lock describes the status of the data item with respect to possible operations that

can be applied to that item. It is used for synchronising the access by concurrent transactions to the database items.

A transaction locks an object before using it. When an object is locked by another transaction, the requesting transaction must wait.

Types of Locks Binary locks have two possible states:

of 10

1. locked (lock_item(X) operation) and2. unlocked (unlock_item(X) operation

Multiple-mode locks allow concurrent access to the same item by several transactions. Three possible states:

1. read locked or shared locked (other transactions are allowed to read the item no oter transaction t can write data object x).

2. write locked or exclusive locked (a single transaction exclusively holds the lock on the item) and

3. unlocked:unlock data object x. Locks are held in a lock table.

Locks can be: upgrade lock: read lock to write lock downgrade lock: write lock to read lock

Locks don’t guarantee serialisability: Lost Update

Example 1

Example 2

of 10

Serial Schedule 1: T1 followed by T2 ⇒ X=50, Y=80 Serial Schedule 2: T2 followed by T1 ⇒ X=70, Y=50 Problem

o Y is unlocked too early in T1o X is unlocked too early in T2

Non-serialisable schedule S that uses locks

X=20, Y=30 result of S ⇒ X=50, Y=50

Ensuring Serialisability: Two-Phase Locking(2pl) Each transaction must obtain a shared lock on object before reading, and an exclusive

lock on object before writing. If a transaction holds an exclusive lock on an object, no other transaction can get a lock

(shared or exclusive) on that object. System can obtain these locks automatically All locking operations (read_lock, write_lock) precede the first unlock operation in the

transactions. Two phases:

o expanding phase: new locks on items can be acquired but none can be released.o shrinking phase: existing locks can be released but no new ones can be acquired.

An example:

of 10

Basic 2PLo When a transaction releases a lock, it may not request another lock

Conservative 2PL or static 2PLo a transaction locks all the items it accesses before the transaction begins

executiono pre-declaring read and write sets

Strict 2PLo 2PL allows only serializable schedules but is subjected to cascading aborts.o Example: rollback of T1 requires rollback of T2!

T1 T2Read(X)Write(X)

Read(X)Write(X)Read(Y)Write(Y)

Abort

o Strict 2PL a transaction does not release any of its locks until after it commits or aborts

o This avoids cascade aborts like the one above.o leads to a strict schedule for recovery

of 10

Lock Manager keeps track of request for locks and grants locks on database objects when they become available.

Locking Problems Deadlock: Each of two or more transactions is waiting for the other to release an

item. Also called a deadly embrace

o Deadlock prevention protocol – deadlock does not occur at all: conservative 2PL

o transaction stamping (younger transactions aborted) no waiting cautious waiting time outs

o Deadlock detection (if the transaction load is light or transactions are short and lock only a few items)

wait-for graph for deadlock detection victim selection cyclic restarts

Livelock: a transaction cannot proceed for an indefinite period of time while other transactions in the system continue normally.

o fair waiting schemes (i.e. first-come-first-served)

Locking Granularity A database item could be

of 10

o a database recordo a field value of a database recordo a disk blocko the whole database

Trade-offso coarse granularity - the larger the data item size, the lower the degree of

concurrencyo fine granularity - the smaller the data item size, the more locks to be

managed and stored, and the more lock/unlock operations needed.

Optimistic Concurrency Control Normally, locking delays transactions, but do not abort them In optimistic mehods, when something goes wrong, abort and restart a transaction

that tries to engage in unserializable behavior No checking while the transaction is executing. Check for conflicts after the transaction. Checks are all made at once, so low transaction execution overhead Relies on little interference between transactions

Updates are not applied until end_transaction Updates are applied to local copies in a transaction space.

Optimistic techniques have three phases:1. read phase: read from the database, but updates are applied only to local copies2. validation phase: check to ensure serialisability. Will not be validated if the

transaction updates are actually applied to the database3. write phase: if validation is successful, transaction updates applied to database;

otherwise updates are discarded and transaction is aborted and restarted.

Concurrency Control by Validation Another type of optimistic concurrency control Maintains a record of what active transactions are doing Just before a transaction starts to write, it goes through a “validation phase” If a there is a risk of physically unrealizable behavior, the transaction is rolled back Keeps track of each transaction T’s

o Read set RS(T): the set of elements transaction T readso Write set WS(T): the set of elements transaction T writes

Execute transactions in three phases:1. Read. transaction T reads all the elements in RS(T)2. Validate. Validate transaction T by comparing its RS(T) and WS(T) with those

in other transactions. If the validation fails, T is rolled back3. Write. transaction T writes its values for the elements in WS(T)

Validation Phase Use transaction timestamps write_sets and read_sets maintained Transaction B is committed or is in its validation phaseValidation Phase for Transaction A To check that Transaction A does not interfere with Transaction B the following must

hold:o Transaction B completes its write phase before Transaction A starts its reads

phase

of 10

o Transaction A starts its write phase after Transaction B completes its write phase, and the read set of Transaction A has no items in common with the write set of Transaction B

o Both the read set and the write set of Transaction A have no items in common with the write set of Transaction B, and Transaction B completes its read phase before Transaction A completes its read phase.

Concurrency control by TimeStamping Timestamping:

o Assign a “timestamp” to each transactiono Record the timestamps of transactions that last read and write each database

element Validation

o Examine timestamps of the transaction and the database element when a transaction is about to commit

Comparison of Three concurrency control Mechanisms Storage utilization

o Locks: space in the lock table is proportional to the number of database elements locked

o Timestamps: Read and write times for recently accessed database elementso Validation: timestamps and read/write sets for each active transaction, plus a few

more transactions that finished after some currently active transaction began Delay

o Locking delays transactions but avoids rollbacks, even when interaction is higho If interference is low, neither timestamps nor validation will cause many transactionso When a rollback is necessary, timestamps catch some problems earlier than validation

of 10

concurrent transactions(what is concurency transaction)

Education