l11 l12 l13 transaction management

47
Rushdi Shams, Dept of CSE, KUET 1

Post on 12-Sep-2014

353 views

Category:

Technology


2 download

DESCRIPTION

 

TRANSCRIPT

Page 1: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 1

Page 2: L11 l12 l13  transaction management

› Action, or series of actions, carried out by user or application, which reads or updates contents of database.

› Transforms database from one consistent state to another, although consistency may be violated during transaction.

Rushdi Shams, Dept of CSE, KUET 2

Page 3: L11 l12 l13  transaction management

Can have one of two outcomes:› Success - transaction commits and database reaches a

new consistent state. › Failure - transaction aborts, and database must be

restored to consistent state before it started. Such a transaction is rolled back or undone.

Committed transaction cannot be aborted. Aborted transaction that is rolled back can be

restarted later.

Rushdi Shams, Dept of CSE, KUET 3

Page 4: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 4

Page 5: L11 l12 l13  transaction management

Process of managing simultaneous operations on the database without having them interfere with one another.

Prevents interference when two or more users are accessing database simultaneously and at least one is updating data.

Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result.

Rushdi Shams, Dept of CSE, KUET 5

Page 6: L11 l12 l13  transaction management

Three examples of potential problems caused by concurrency:

1. Lost update problem.2. Uncommitted dependency problem.3. Inconsistent analysis problem.

Rushdi Shams, Dept of CSE, KUET 6

Page 7: L11 l12 l13  transaction management

Successfully completed update is overridden by another user.

T1 withdrawing £10 from an account with balx, initially £100.

T2 depositing £100 into same account. Serially, final balance would be £190.

Rushdi Shams, Dept of CSE, KUET 7

Page 8: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 8

Page 9: L11 l12 l13  transaction management

Occurs when one transaction can see intermediate results of another transaction before it has committed.

T4 updates balx to £200 but it aborts, so balx should be back at original value of £100.

T3 has read new value of balx (£200) and uses value as basis of £10 reduction, giving a new balance of £190, instead of £90.

Rushdi Shams, Dept of CSE, KUET 9

Page 10: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 10

Page 11: L11 l12 l13  transaction management

Occurs when transaction reads several values but second transaction updates some of them during execution of first.

Sometimes referred to as dirty read or unrepeatable read.

T6 is totaling balances of account x (£100), account y (£50), and account z (£25).

Meantime, T5 has transferred £10 from balx to balz, so T6 now has wrong result (£10 too high).

Rushdi Shams, Dept of CSE, KUET 11

Page 12: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 12

Page 13: L11 l12 l13  transaction management

Objective of a concurrency control protocol is to schedule transactions in such a way as to avoid any interference.

Could run transactions serially, but this limits degree of concurrency or parallelism in system.

Serializability identifies those executions of transactions guaranteed to ensure consistency.

Rushdi Shams, Dept of CSE, KUET 13

Page 14: L11 l12 l13  transaction management

Sequence of reads/writes by set of concurrent transactions.

There are 2 types of scheduling-1. Serial scheduling2. Non serial scheduling

Rushdi Shams, Dept of CSE, KUET 14

Page 15: L11 l12 l13  transaction management

› Schedule where operations of each transaction are executed consecutively without any interleaved operations from other transactions.

Rushdi Shams, Dept of CSE, KUET 15

Page 16: L11 l12 l13  transaction management

Schedule where operations from set of concurrent transactions are interleaved.

Rushdi Shams, Dept of CSE, KUET 16

Page 17: L11 l12 l13  transaction management

Objective of serializability is to find nonserial schedules that allow transactions to execute concurrently without interfering with one another.

In other words, want to find nonserial schedules that are equivalent to some serial schedule. Such a schedule is called serializable.

Rushdi Shams, Dept of CSE, KUET 17

Page 18: L11 l12 l13  transaction management

In serializability, ordering of read/writes is important:

1. If two transactions only read a data item, they do not conflict and order is not important.

2. If two transactions either read or write completely separate data items, they do not conflict and order is not important.

3. If one transaction writes a data item and another reads or writes same data item, order of execution is important.

Rushdi Shams, Dept of CSE, KUET 18

Page 19: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 19

Page 20: L11 l12 l13  transaction management

Used to test for serializability Create

› node for each transaction;› a directed edge Ti Tj, if Tj reads the value of an

item written by Ti;› a directed edge Ti Tj, if Tj writes a value into an

item after it has been read by Ti. If precedence graph contains cycle you are in

trouble!!

Rushdi Shams, Dept of CSE, KUET 20

Page 21: L11 l12 l13  transaction management

T9 is transferring £100 from one account with balance balx to another account with balance baly.

T10 is increasing balance of these two accounts by 10%.

Precedence graph has a cycle and so is not serializable.

Rushdi Shams, Dept of CSE, KUET 21

Page 22: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 22

Page 23: L11 l12 l13  transaction management

Serializability identifies schedules that maintain database consistency, assuming no transaction fails.

Could also examine recoverability of transactions within schedule.

Rushdi Shams, Dept of CSE, KUET 23

Page 24: L11 l12 l13  transaction management

A schedule is recoverable if, for each pair of transactions Ti and Tj, if Tj reads a data item previously written by Ti, then the commit operation of Ti precedes the commit operation of Tj.

Rushdi Shams, Dept of CSE, KUET 24

Page 25: L11 l12 l13  transaction management

1. Optimistic method:› Based on assumption that conflict does not happen

very often. › So we better let the transaction run to its

completion and then check at commit time to see if there is a conflict.

› If there is, the offending transaction simply starts again from the beginning.

Rushdi Shams, Dept of CSE, KUET 25

Page 26: L11 l12 l13  transaction management

2. Timestamping: › For any given database request, the system

compares the timestamp of the requesting transaction with the timestamp of the transaction that last retrieved or updated the requested record.

› If there is a conflict, the requesting transaction can simply be restarted (with new timestamp).

Rushdi Shams, Dept of CSE, KUET 26

Page 27: L11 l12 l13  transaction management

3. Locking:› When a transaction needs an assurance that

transaction will not be affected by others, it requires a lock on that object.

› Then the first transaction is able to carry out its processing without fear of others’ interference.

Rushdi Shams, Dept of CSE, KUET 27

Page 28: L11 l12 l13  transaction management

Exclusive Lock (XLock): If anybody is having exclusive lock, the other users will go into wait list until the exclusive lock holder releases it.

Shared Lock (SLock): If anybody has shared lock, the other users with request shared lock can also have access to it.

Rushdi Shams, Dept of CSE, KUET 28

Page 29: L11 l12 l13  transaction management

If A has XLock, then if B wants XLock, B has to wait then if B wants SLock, B has to wait then if B wants NoLock, B can see it

If A has SLock, then if B wants XLock, B has to wait then if B wants SLock, B gets permission then if B wants NoLock, B can see it

If A has NoLock, then if B wants XLock, B will be granted then if B wants SLock, B will be granted then if B wants NoLock, B will be granted

Xlock= Exclusive Lock SLock= Shared Lock

Rushdi Shams, Dept of CSE, KUET 29

Page 30: L11 l12 l13  transaction management

If transaction has shared lock on item, can read but not update item.

If transaction has exclusive lock on item, can both read and update item.

Reads cannot conflict, so more than one transaction can hold shared locks simultaneously on same item.

Rushdi Shams, Dept of CSE, KUET 30

Page 31: L11 l12 l13  transaction management

Problem is that transactions release locks too soon, resulting in loss of total isolation and atomicity.

To guarantee serializability, need an additional protocol concerning the positioning of lock and unlock operations in every transaction.

Rushdi Shams, Dept of CSE, KUET 31

Page 32: L11 l12 l13  transaction management

Transaction follows 2PL protocol if all locking operations precede first unlock operation in the transaction.

Two phases for transaction:› Growing phase - acquires all locks but cannot

release any locks.› Shrinking phase - releases locks but cannot acquire

any new locks.

Rushdi Shams, Dept of CSE, KUET 32

Page 33: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 33

Page 34: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 34

Page 35: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 35

Page 36: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 36

Page 37: L11 l12 l13  transaction management

Transactions conform to 2PL. T14 aborts. Since T15 is dependent on T14, T15 must also be

rolled back. Since T16 is dependent on T15, it too must be rolled back.

This is called cascading rollback. To prevent this with 2PL, leave release of all

locks until end of transaction.

Rushdi Shams, Dept of CSE, KUET 37

Page 38: L11 l12 l13  transaction management

An impasse that may result when two (or more) transactions are each waiting for locks held by the other to be released.

Deadlock is a situation in which two or more transactions are in a simultaneous wait state; each one waiting for one of the other to release a lock before it can proceed.

Rushdi Shams, Dept of CSE, KUET 38

Page 39: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 39

Page 40: L11 l12 l13  transaction management

Deadlock should be transparent to user, so DBMS should restart transaction(s).

Three general techniques for handling deadlock:

1. Timeouts.2. Deadlock prevention.3. Deadlock detection and recovery.

Rushdi Shams, Dept of CSE, KUET 40

Page 41: L11 l12 l13  transaction management

Transaction that requests lock will only wait for a system-defined period of time.

If lock has not been granted within this period, lock request times out.

In this case, DBMS assumes transaction may be deadlocked, even though it may not be, and it aborts and automatically restarts the transaction.

Rushdi Shams, Dept of CSE, KUET 41

Page 42: L11 l12 l13  transaction management

DBMS looks ahead to see if transaction would cause deadlock and never allows deadlock to occur.

Wait-Die - only an older transaction can wait for younger one, otherwise If younger transaction requests lock held by olderone, younger one is aborted (dies) and restartedwith same timestamp.

Rushdi Shams, Dept of CSE, KUET 42

Page 43: L11 l12 l13  transaction management

› Wound-Wait - only a younger transaction can wait for an older one. If older transaction requests lock held by younger one, younger one is aborted (wounded).

Rushdi Shams, Dept of CSE, KUET 43

Page 44: L11 l12 l13  transaction management

DBMS allows deadlock to occur but recognizes it and breaks it.

Usually handled by construction of wait-for graph (WFG) showing transaction dependencies:› Create a node for each transaction.› Create edge Ti -> Tj, if Ti waiting to lock item

locked by Tj. Deadlock exists if and only if WFG contains cycle.

Rushdi Shams, Dept of CSE, KUET 44

Page 45: L11 l12 l13  transaction management

Rushdi Shams, Dept of CSE, KUET 45

Page 46: L11 l12 l13  transaction management

Selecting a victim – minimize cost.

Rollback – return to some safe state, restart transaction for that state.

Starvation – same transaction may always be picked as victim, include number of rollback in cost factor.

Rushdi Shams, Dept of CSE, KUET 46

Page 47: L11 l12 l13  transaction management

Database Management Systems by R. Ramakrishnan

John Hall, Senior Lecturer, University of Bolton, UK

Operating Systems Concept (6th Edition) by Silberschatz, Galvin and Gagne

Rushdi Shams, Dept of CSE, KUET 47