Introduction to Transaction Processing 2

8/14/2019 Introduction to Transaction Processing 2

http://slidepdf.com/reader/full/introduction-to-transaction-processing-2 1/44

Introduction to Transaction

Processing

DBMS



Typical OLTP Environments

• Airline/ Railway Reservation Systems

• Banking Systems (ATM, EFT, ...)

• Trading and Brokerage Systems

• Hotel / Hospital Systems

• Standard Commercial Systems



Types of Failures

• occurs several times a week

• recovery required in a fewminutes



Types of Failures

• occurs intermittently

• recovery time depends on the nature of

failure



Types of Failures

• occurs once or twice a year

• recovery required in a few hours



Types of Failures

• occurs 10-100 times in a minute

• recovery required in transaction execution

time



Motivating Scenario

Bank 1 Bank 2

0: (Acct.2565) bal += 2500

3: (Acct.165) bal -= 2500

Account #165 from bank 2 sends Rs. 2500/- to Account #2565

in bank 1.



Motivating Scenario

Bank 1 Bank 2

0: (Acct.2565) bal += 2500

3: (Acct.165) bal -= 2500


in bank 1.

B a n k

2 c r a

s h e s a t t

i m e =

2



Motivating Scenario

Bank 1 Bank 2

0: (Acct.2565) bal += 2500

1: (Acct.165) bal -= 1500

3: (Acct.165) bal -= 2500


in bank 1.



Transactions

• A transaction is a logical unit of program

execution

• A combination of database updates which

have to be performed together



What is a Transaction?

A logical unit of work.A logical unit of work.




A unit of work A unit of work

with respect towith respect toconcurrency and recovery.concurrency and recovery.




A sequence of operationsA sequence of operations

including database operationsincluding database operations

that is atomic with respect tothat is atomic with respect to

concurrency and recovery.concurrency and recovery.




An atomic execution unit that,An atomic execution unit that,

when applied to a consistentwhen applied to a consistent

database, generates adatabase, generates a

consistent but possiblyconsistent but possibly

different database.different database.




short sequence of operationsshort sequence of operationsith the database whichith the database which

epresents one meaningfulepresents one meaningful

ctivity in the user's environment.ctivity in the user's environment.



ACID Property of Transactions

• Atomicity: Either all updates are performed or none

•Consistency: If the database state at the start of atransaction is consistent, it will be consistent at theend of the transaction

• Isolation: When multiple transactions are executedconcurrently, the net effect is as though eachtransaction has executed in isolation

• Durability: After a transaction completes(commits), its changes are persistent



Atomicity

Consider the case of funds transfer from account A to account B.

A.bal -= amount;

B.bal += amount;

A.bal -= amount;

CRASH

…

…

RECOVERY

A.bal += amount;

Rollback



Consistency


A.bal -= amount;

B.bal += amount;

B.bal += amount;

A.bal -= amount (FAILS!! A’s balance is 0)

B.bal -= amount;

Rollback



Isolation


Transaction T1:

A.bal -= amount; (Let A’s balance become 0 after this…)B.bal += amount;

Transaction T2:

A.bal -= amount2;

Net effect should be either T1,T2 (in which case T2 fails) or

T2,T1 (in which case T1 fails)



Durability


Account A should have a balance of amount

Transaction T1:

A.bal -= amount;

B.bal += amount;

Commit

Account A should have a balance of 0.



Transaction States

Active

Partially

Committed

Failed

Committed

Aborted



ACD using Shadow Copy

DB

DBCopy of

DB

DB’



ACD Using Shadow Copy

• Atomicity: Delete old DB on commit or

new DB on Failed transactions (all or

nothing)• Consistency: Delete new DB, if update

fails.

• Isolation: Not supported..

• Durability: One of the copies is persistent



Serializability

On executing a set of concurrent transactions on a database the

net effect should be as though the transactions were executed

in some serial order.

Transaction T1:

read (A)

A = A – 50;write (A)

read (B)

B = B + 50;

write (B)

Transaction T2:

read (A)

t = A * 0.1;

A = A – t;write (A)

read (B)

B = B + t;

write (B)



Serial Schedules

read (A)

A = A – 50;

write (A)

read (B)B = B + 50;

write (B)

read (A)

t = A * 0.1;A = A – t;

write (A)

read (B)

B = B + t;

write (B)

Equivalent to T1

followed by T2



Serial Schedules

read (A)

A = A – 50;write (A)

read (B)

B = B + 50;

write (B)

read (A)

t = A * 0.1;

A = A – t;

write (A)read (B)

B = B + t;

write (B)

Equivalent to T2

followed by T1



Serial Schedules

read (B)

B = B + t;write(B)

read (B)

B = B + 50;

write (B)

read (A)

t = A * 0.1;

A = A – t;

write (A)read (A)

A = A – 50;

write (A)

Equivalent to T1

followed by T2



Conflict Serializability

Let instructions I and J belonging to transactions T1 and T2

be executed consecutively by the DBMS.

1. I and J can be swapped in their execution order if I and J

refer to different data elements

2. I and J can be swapped in their execution order iff I and J

refer to the same data element and both perform a read

operation only.

3. I and J are said to conflict if I and J belong to different

transactions and at least one of them is a write operation.



Conflict Serializability

• If a schedule S can be transformed to another S’ by

swapping non conflicting instructions, then S and S’ are

said to be conflict equivalent .

• A schedule S is said to be conflict serializable if it is

conflict equivalent to some serial schedule.



View Serializability

If S is a schedule, then S’ is a view equivalent schedule if

• For each data item Q, if a transaction Ti reads the initialvalue of Q in S, then it should read the initial value in S’

also• In schedule S, for each data item Q, if write(Q) of Tj

precedes read(Q) of Ti, it should be the same in S’

• The same transaction that performs the final write(Q) in S,

should perform it in S’.




T1:

Read(Q)

Write (Q)

T2:

Write (Q)T3:

Write(Q)

A view equivalent schedule:

T1: Read(Q)T2: Write(Q)

T1: Write(Q)

T3: Write(Q)




• Every conflict serializable schedule is alsoview serializable; however some view

serializable schedules are not conflictserializable

• Example in previous slide

• A schedule that is view serializable but notconflict serializable is characterized byblind writes.



Recovery

• So far study of schedules that are acceptable fromthe viewpoint of consistency of database-

assuming no transaction failures.

• If transaction T fails- undo the effect of the

transaction to ensure atomicity.• Also, it is necessary to abort any other transaction

T1 that is dependent on T.

• To achieve the above two, restrictions on the typeof schedules permitted has to be laid down.



Recoverable Schedules

• Consider the following schedule

T8 T9

read(A)

write(A)

read(A)

read(B)



Recoverable Schedules

• Suppose T9 commits before T8• If T8 fails before it commits then T9 also

has to be aborted.

•However, T9 is already committed.• A situation where it is impossible to recover from the failure of T8

• This is an example of non recoverableschedule

• Database systems require recoverableschedules.



Cascading Rollback

• Even if a schedule is recoverable, to recover from the

failure of a transaction, there is a need to rollback severaltransactions.

T T1 T2

read(A)

read(B)write(A)

read(A)

write(A)

read(A)if T fails, then it will lead to rolling back T1 and T2.

This is an example of cascading rollback.



Cascadeless Schedule

• Cascading rollback is undesirable- leads toundoing a lot of work

• Restrict the schedules to those where

cascading rollbacks do not occur.• Such schedules are cascadeless schedule.

l f l



Implementation of Isolation

• Concurrency-control schemes to ensure that even

when multiple transactions are executedconcurrently,only acceptable schedules aregenerated.

• An example, a transaction acquires a lock on an

entire database before it starts and then releasesthe lock after it finishes.

• No other transaction is allowed to access thedatabase.

• Therefore, only serializable schedules are produced.



Implementation of isolation …

• The above discussed scheme leads to poor

performance.

• Goal of such schemes is to provide a highdegree of concurrency.



Transaction definition in SQL

• SQL provides TCL(Transaction controllanguage)

• Commit- commits the current transaction

and begins a new one• Rollback- causes the current transactions to

abort

f l b l



Testing for serializability

• When designing concurrency control schemes, wemust show that schedules generated by the schemeare serializable.

• A directed graph called precedence graph is used

for this purposeT1 ------- T2

• This indicates that all transactions of T1 areexecuted before T2

• T2 ------ T1• This indicates that all transactions of T2 are

executed before T1



Testing for Serializability…

• If the precedence graph for a schedule s has a

cycle, then s is not conflict serializable.

• If the precedence graph for a schedule s does nothave a cycle, then s is conflict serializable.

• Serializability order of the transaction obtained

through topological sorting which determines a

linear order consistent with the partial order of the precedence graph

Introduction to Transaction Processing 2

Documents

Transcript of Introduction to Transaction Processing 2