Introduction-to-transaction-processing2

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 few minutes

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


Bank 2 crashes at time=2

Motivating Scenario

Bank 1 Bank 2

0: (Acct.2565) bal += 25001: (Acct.165) bal -= 15003: (Acct.165) bal -= 2500


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 to with respect to

concurrency and recovery.concurrency and recovery.


A sequence of operationsA sequence of operationsincluding database operationsincluding database operationsthat is atomic with respect to that 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 consistent when applied to a consistent

database, generates a database, generates a

consistent but possibly consistent but possibly

different database.different database.


A short sequence of operations A short sequence of operations with the database which with the database which

represents one meaningful represents one meaningful

activity in the user's environment.activity 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 a

transaction is consistent, it will be consistent at the end of the transaction

• Isolation: When multiple transactions are executed concurrently, the net effect is as though each transaction 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……RECOVERYA.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: Initial state; when the transaction is

executing • Partially Committed: When the last statement has

finished execution • Failed: On discovery that normal execution can no

longer proceed • Aborted: After the rollback is performed from a

failed transaction • Committed: After successful completion• Terminated: Either committed or aborted

Transaction States

Active

PartiallyCommitted

Failed

Committed

Aborted

ACD using Shadow Copy

• Simple but extremely inefficient implementation

• Assumes database to be a file

• Assumes only one transaction is active at any time

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



Equivalent to T1 followed by T2

Serial Schedules




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)


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 initial value 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 also view serializable; however some view serializable schedules are not conflict serializable

• Example in previous slide • A schedule that is view serializable but not

conflict serializable is characterized by blind writes.

Recovery

• So far study of schedules that are acceptable from the 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 type of 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 recoverable

schedule• Database systems require recoverable

schedules.

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

failure of a transaction, there is a need to rollback several transactions.

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 to undoing a lot of work

• Restrict the schedules to those where cascading rollbacks do not occur.

• Such schedules are cascadeless schedule.

Implementation of Isolation

• Concurrency-control schemes to ensure that even when multiple transactions are executed concurrently,only acceptable schedules are generated.

• An example, a transaction acquires a lock on an entire database before it starts and then releases the lock after it finishes.

• No other transaction is allowed to access the database.

• 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 high degree of concurrency.

Transaction definition in SQL

• SQL provides TCL(Transaction control language)

• Commit- commits the current transaction and begins a new one

• Rollback- causes the current transactions to abort

Testing for serializability

• When designing concurrency control schemes, we must show that schedules generated by the scheme are serializable.

• A directed graph called precedence graph is used for this purpose

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

executed 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 not have 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-processing2

Documents

bal amount

view equivalent

view serializable

conflict serializable

transaction

transaction

motivating

funds transfer