Database design and Implementation 10.Transaction

8/8/2019 Database design and Implementation 10.Transaction

1/11

Database Systems Implementation, Bongki Moon 1

Transactions andSerializability

Ramakrishnan & Gehrke

Chap. 16.1-16.3


Review: Core Functions of DBMS

So far, our focus has been mainly on efficiency.

In addition to providing fast access to data, ...

Protect mission-critical data.

Provide correct and highly available (7x24) accessin the presence of concurrent access by large and

diverse users. Heavy-duty transactions and ad-hoc queries

Survive various S/W and H/Wfailures.


2/11


Why Have Concurrent Processes?

Better transaction throughput, response time viabetter utilization of resources While one processes is doing a disk read, another can be

using the CPU or reading another disk.

A degree of fairness in access to resources.

DANGER!DANGER! Concurrency could lead to incorrectness! Must carefully manage concurrent data access.

Theres (much!) more here than the usual OS tricks!


Transactions

A transactiontransaction is typically an application program (written inC/C++) with embedded SQL statements.

From the DBMSs point of view, a transaction is a series ofthe following actions: READs: DB object is read from disk into buffer page. WRITEs: DB object is written from buffer to disk. ABORT: Last action of a Xact that fails. COMMIT: Last action of a Xact that succeeds.

These are the only operations that can change the state of adatabase. The effects of aborted Xacts must be undone (or rolled back)

completely. DB is modified permanently only by committed Xacts.


3/11


Concurrency in a DBMS

Users submit transactions, and can think of each transaction asexecuting by itself. (Give users such illusion.)

Concurrency is achieved by the DBMS, which interleavesactions (reads/writes of DB objects) of various transactions.

Each transaction must leave the database in a consistentstate if the DB is consistent when the transaction begins. DBMS will enforce some Integrity Constraints (IC), depending on

the ICs declared in CREATE TABLE statements.

Beyond this, the DBMS does not really understand the semantics of

the data. (e.g., it does not understand how the interest on a bankaccount is computed).

Issues: Effect of interleaving transactions, and crashes.


Properties of Transactions (ACID)

Atomicity: Xact is all-or-nothing. If system crashes, partially done Xacts must be undone

or rolled back.

Consistency: If each Xact is consistent, and the DBstarts consistent, it ends up consistent.

Isolation: Xacts are shielded from the effects ofother concurrent Xacts.

Concurrency is for performance; must not affectmeaning of each Xact.

Durability: If a Xact commits, its changes mustbe guaranteed to survive crashes.


4/11


Passing the ACID Test

Atomicity: Keep track of the changes made by each activeXact; if a crash occurs undo the changes of partial Xacts.

Durability: Keep track of the changes made by eachcommitted Xact; if a crash occurs, redo the changes thathave not been written to disk.

Isolation: Ensure that an Xact only sees(reads/overwrites) changes made by committed Xacts.

Consistency: Follows from the other three; may requirerun-time triggers for integrity constraints.


Static Database Assumption

DB is a fixed collection of objects (units in whichinfo is written to/read from DB, e.g., pages). Assume that pages are not added or deleted. That is,

assume a fixed set of data pages.

(Will relax this shortly.)


5/11


Example: Balance Transfer

Consider two transactions:T1: A=A+100, B=B-100T2: Read(A), Read(B), Print(A+B)

T1 is transferring $100 from Bs account to Asaccount. T2 is reporting the sum of the balances.

For T1, a required invariant is A + B = A0 + B0.

However, at several points during T1, database is in

a temporarily inconsistent state. Do you see them? T1: R(A), W(A), R(B), W(B).


Example: Inconsistent retrieval

There is no guarantee that T1 will execute before T2 orvice-versa, if both are submitted together. They may beinterleaved too.

T1: A=A+100, B=B-100T2: Read(A,B), Print A+B

T2 can see an inconsistent DB state. T2 may print A0+B0 or A0+B0+100.

This is a violation of the Isolation Test.

The net effect of concurrent execution must be equivalentto the two transactions running serially in some order.

SerializabilitySerializability is the formal notion of correctness forconcurrent execution.


6/11


Schedule

A schedule is a list of actions (read, write, abort,commit) of a set of transactions. Show how operations are interleaved.

T1 T2

R(A)W(A)

R(A)R(B)

R(B)

W(B)

oldest action

newest action

Schedule: R1(A) W1(A) R2(A) R2(B) R1(B) W1(B)


Examples of Schedules

Consider the following two schedules.

T1: A=A+100, B=B-100T3: A=1.06*A, B=1.06*B

T1: A=A+100, B=B-100T3: A=1.06*A, B=1.06*B

Are they correct? In other words, is the result produced by each of the

schedules can be obtained by either of the serial schedules T1-then-T3and T3-then-T1?

How do you know a schedule is correct?

For a set of Ntransactions, there are N! serial schedules. You canttry all of them!!


7/11


Conflicting Operations

Two operations by differenttransactions conflict when theyaccess the same item, and atleast one of them isWRITE.

W1(A)-R3(A), W1(A)-W3(A),R3(B)-W1(B), W3(B)-R1(B), etc.

T1 T3

R(A)

W(A)

R(A)

W(A)

R(B)

W(B)

Commit

R(B)

W(B)

Commit

transfer$100 fromA to B

add 6%interest toA & B

Database isinconsistent!


Anomalies by Conflicts

WR Conflicts (Dirty Read) T1 leaves database in an inconsistent state afterW(A).

T3 read A modified by an uncommitted transaction T1.

RW Conflicts (Unrepeatable Read) T3 overwrites what T1 read. (E.g., A)

If T1 reads it again, it will see something new!

Again, not equivalent to a serial execution. WW Conflicts (Overwriting Uncommited Data)

T3 overwrites what T1 wrote.

Any of these violates the Isolation Property.


8/11


Serializable (SR) Schedules

Two schedules are equivalent if(1) defined over the same set of Xacts and operations,

(2) same intra-xact order of operations, and

(3) same inter-xact order of conflicting operations.

Equivalent schedules:

A schedule is serializableserializable if it is equivalent to someserial schedule. S2 is serializable because S1 is a serial schedule.

S1: R1(A)W1(A) R1(B) W1(B) C1R2(A) R2(B) C2S2: R1(A) W1(A) R2(A) R1(B) W1(B) C1R2(B) C2


Serializable Schedules (contd)

Is this schedule serializable?R1(A) W1(A) R2(A) R2(B) C2R1(B) W1(B) C1

Use Dependency Graph to determine the serializability. T1 T2 DG if O1(A) < O2(A) and O1 and O2 are conflicting

operations.

DBMS guarantees that all executed schedules will beserializable, but makes no guarantees about whichparticular serial order of Xacts is simulated. We dont need to know which one of the N! serial schedules it is.

We just need to know whether it is serializable or not.


9/11


Problems with Aborted Transactions

The effects of all incomplete or aborted Xacts must becompletely undone, in order for serializability to be auseful property!

Serializable schedule: Equivalent to a serial schedule ofcommitted Xacts. as if aborted Xacts never happened.

Two Issues:

Cascading aborts

Recoverability


Cascading Aborts

WR conflicts & Aborts?

Abort of T1 requires abort of T2!

To avoid cascading aborts, a Xact must

read data only from committed Xacts.

A schedule isACA (avoids cascading abort)ACA (avoids cascading abort) if

whenever Tj reads x from Ti (i.e., Wi[x] < Rj[x]),then it must be that ci < Rj[x]. No Dirty Reads are allowed.

T1 T2

R(A)

W(A)

R(A)

W(A)

abort


10/11


Recoverable Schedules

Abort of T1 requires abort of T2! But T2 has already committed!

To be recoverable, a Xact commits only

after all the Xacts it depends on commit.

A schedule is RC (recoverable)RC (recoverable) if whenever Tj readsfrom Ti (i.e., Wi[x] < Rj[x]), it must be that ci < cj. Unlike ACA, Dirty Reads are allowed.

Real systems typically ensure that onlyrecoverable schedules arise (through locking).

T1 T2

R(A)

W(A)

R(A)

W(A)

commit

abort


Strict Schedules

With WW conflicts, undoing an aborted Xact withbefore-values is difficult. T2 overwrites a value that T1 writes; then T1 aborts.

When T1s remembered values are restored, we lostT2s write!

To avoid this, Xacts only read/write changes ofterminated Xacts.

A schedule is ST (strict)ST (strict) if whenever wi[x] < oj[x],it must be either ai < oj[x] or ci < oj[x].


11/11


Relationships between Schedules

Serial Strict ACA RC, Serial Serializable

Serializable Strict, Strict Serializable.


Summary

Concept of transaction central to DBMS CC.

Transactions and the ACID properties: C & I are handled by concurrency control.

A & D coming soon with logging & recovery.

Concurrency Control Guarantees Consistency and Isolation, given Atomicity.

Logging and Recovery

Guarantees Atomicity and Durability. Serial execution is our model of correctness.

Schedule must be equivalent to some serial execution of Xactions.

Desirable properties of schedules: SR, RC, ACA, Strict (ST).

Database design and Implementation 10.Transaction

Documents

Transcript of Database design and Implementation 10.Transaction