Transaction

02/23/2005 Yan Huang - CSCI5330 Database Implementation – Transaction

Transaction


Outline

Transaction and OLTP Desired properties of transactions Schedule Concurrent transactions and their properties


Transaction

A multi-billion dollar business OLTP http://www.tpc.org/default.asp


Transaction Definition

A unit of program execution that accesses and possibly updates various data items

Transactions? Book an airline ticket from DFW to Paris Buy “The Dilbert Principle” from amazon.com Sell 1000 shares of LU from your ameritrade account Withdraw $100 from a ATM machine Issue a SQL statement to sqlplus of Oracle 9i Look at your grade of homework 3 Check out your groceries at Walmart


Transaction Concept

A transaction is a unit of program execution that accesses and possibly updates various data items.

Two main issues to deal with: Failures of various kinds, such as hardware failures and

system crashes Concurrent execution of multiple transactions

a1, a2, a3, a4, …, an, commit

Database may be inconsistentconsistent consistent

c1, c2, c3, c4, …, cl, commit

b1, b2, b3, b4, …, bm, commit



Challenges to Maintain Transactions

Hardware failures Cashed stuck in ATM machine Power failure…

Software failures Programming errors System crash…

User interference Termination of transactions

Concurrent users Multiple users accessing the same item


Designed Properties of Database Systems

Atomicity Consistency Isolation Durability


Atomicity

Transaction needs to be executed as a unit Example

You should not cause the quantity of “The Dilbert Principle” of amazon.com decrease if you place your order and the order does not get through due to server errors

Who are responsible for atomicity? Transaction management system and Recovery system


Example of Fund Transfer

Transaction to transfer $50 from account A to account B:

1. read(A)

2. A := A – 50

3. write(A)

4. read(B)

5. B := B + 50

6. write(B)

7. commit


Atomicity

Either all operations of the transaction are properly reflected

Or none are

(1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50, (6)write(B), (7) commit

(1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50


Consistency

Database implicit/explicit constraints need to be maintained

Example: Transferring money from one account to another in the same

bank should not change your total amount of money

Who are responsible for consistency? Transaction management system and Programmer


Consistency

A+B = TOT where TOT is a constant value

Consistency: DB satisfies all integrity and constraints Examples:

- x is key of relation R - x y holds in R - Domain(x) = {Red, Blue, Green} is valid index for attribute x of R no employee should make more than twice the average salary A+B = TOT

A+B may not equal to TOTA+B= TOT A+B= TOT



Isolation

Transaction A should not see partial results of transaction B

Analogy: When I update my website here and there, you should not see

and think a tentative version as my final version

Who are responsible for isolation? Transaction management system


Isolation

Intermediate transaction results must be hidden from other concurrently executed transactions.

A+B may not equal to TOTA+B= TOT A+B= TOT

T2

A+B ≠ TOT?!



Durability

Any transaction committed needs to be in database for ever

Example: After you get the receipt of the water melon you buy from

Alberson, the transaction is final and permanently reflected in the database system If you want to cancel it, that is another transaction

Who are responsible for durability? Transaction management system and Recovery system


Durability

After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures.

After this point, A and B are permanently updated



Transaction State (Cont.)



An Ideal World

No hardware failures No software failures No programming errors Do we still need transaction management?


Why Concurrent Transactions?

Parallelism Improved response time


Storage Hierarchy

Read(x) read x from memory, if it is not in memory yet, read from disk first

Write(x) writes x to memory and possibly to disk

Memory Disk

x x

1. read(A)

2. A := A – 50

3. write(A)

4. read(B)

5. B := B + 50

6. write(B)

7. commit


SchedulesT1

Read(A)

A:=A-50

Write(A)

Read(B)

B:=B+50

Write(B)

T2

Read(A)

Temp:=A*0.1

A:=A-temp

Write(A)

Read(B)

B:=B+temp

Write(B)

Schedule 1

Read(A)A:=A-50Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)Write(A)Read(B)B:=B+50Write(B)

B:=B+tempWrite(B)

T1 transfer $50 from A to B

T2 transfer 10% of the balance from A to B


Schedules

Schedules – sequences that indicate the chronological order in which instructions of concurrent transactions are executed a schedule for a set of transactions must consist of all

instructions of those transactions must preserve the order in which the instructions appear in

each individual transaction.


Serial Schedule

T1 is followed by T2.

A = 100, B = 100 originally

A = ? and B = ?

Schedule 2

Read(A)A:=A-50Write(A)Read(B)B:=B+50Write(B)Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)

B:=B+tempWrite(B)


Example Schedule (Cont.)

Schedule 3 is equivalent to Schedule 1.

In both Schedule 2 and 3, the sum A + B is preserved.


A = ? and B = ?

Schedule 3

Read(A)A:=A-50Write(A)Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)B:=B+50Write(B)Read(B)

B:=B+tempWrite(B)


Example Schedules (Cont.)


A = ? and B = ?

Schedule 4 does not preserve the sum A + B

Schedule 4

Read(A)A:=A-50Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)Write(A)Read(B)B:=B+50Write(B)

B:=B+tempWrite(B)


Where is the mystery?

How to preserve database consistency?

Serializability!


Serializability

A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.


Conflict Serializability

Transactions T1 and T2

Two operations on the same item Q,

Intuitively, a conflict between T1 and T2 forces a (logical) temporal order between T1 and T2 .

Two consecutive non-conflict operations in a schedule can been interchanged

Read(Q) Write(Q)

Read(Q)

Write(Q)

T1T2

Conflict?


Conflict Serializability (Cont.)

If a schedule S can be transformed into a schedule S´ by a series of swaps of non-conflicting instructions, we say that S and S´ are conflict equivalent.


Note

Only read and write operations will cause conflict Other operations (A:=A+10) are on local copy variables

and do not interface with database


Simplified SchedulesSchedule 3

Read(A)A:=A-50Write(A)Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)B:=B+50Write(B)Read(B)

B:=B+tempWrite(B)

Schedule 3

Read(A)Write(A)Read(A)Write(A)Read(B)Write(B)Read(B)Write(B)

Schedule 2

Read(A)Write(A)Read(B)Write(B)Read(A)Write(A)Read(B)Write(B)

Schedule 2

Read(A)A:=A-50Write(A)Read(B)B:=B+50Write(B)Read(A)

Temp:=A*0.1A:=A-tempWrite(A)Read(B)

B:=B+tempWrite(B)


Schedule 3 and Schedule 2 are conflict equivalent

Schedule 3


Schedule 2




Schedule 3

Read(A)Write(A)Read(A)Read(B)Write(A)Write(B)Read(B)Write(B)

Schedule 2




Schedule 3

Read(A)Write(A)Read(A)Read(B)Write(B)Write(A)Read(B)Write(B)

Schedule 2




Schedule 3

Read(A)Write(A)Read(B)Read(A)Write(B)Write(A)Read(B)Write(B)

Schedule 2




Schedule 3


Schedule 2



Conflict Serializability (Cont.)

We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule

Schedule 3 is conflict serializable


Conflict Serializability (Cont.) Example of a schedule that is not conflict

serializable:

T3 T4

read(Q)

write(Q)write(Q)

We are unable to swap instructions in the above schedule to obtain either the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.


Testing for Serializability

Precedence graph — a direct graph where the vertices are the transactions (names).


Example Schedule (Schedule A)T1 T2 T3 T4 T5

read(X)read(Y)read(Z)

read(V)read(W)read(W)

read(Y)write(Y)

write(Z)read(U)

read(Y)write(Y)read(Z)write(Z)

read(U)write(U)


Precedence Graph for Schedule A

T3

T4

T1 T2

T5


Recoverability

Only commit after the transaction your read from commits


Cascadeless Schedule

Only read committed write


Check SchedulesSchedule 1

Read(A)Read(A)Write(A)Read(B)Write(A)Read(B)Write(B)Write(B)

Schedule 2


Schedule 3


Schedule 4

Read(A)Read(A)Write(A)Read(B)Write(A)Read(B)Write(B)Write(B)

Conflict serializable?

Recoverable?

Cascadeless?

Transaction

Documents

Transcript of Transaction