Transaction Processing Lecture ACID 2 phase commit

What is a transaction? It is a program, executing within a database application on data in the DB. The DB instance reflects the current state of the world. A transaction is used to: –Update the state of the DB to reflect the world’s new state. –Effect ( trigger ) a real-world event, depending on new state or a state transition in the DB. –Return DB’s current state information.

Unlike a program, a transaction must maintain a consistent DB instance. –Even if system crashes or there are multiple interleaved accesses to the same data element. –ACID properties help to maintain data consistency. Atomic Consistent Isolated Durable

ACID –Consistent, essentially, means that all the data reflect the current real world state. –Further, no action can be taken on the DB that creates an instance that violates business rules.

ACID Integrity constraints: Examples –Domain constraints -- set of values allowed for an attribute (e.g., can’t be NULL, or must be INT). –Referential integrity -- a value for a foreign key must appear in the related primary key field (in a different table). –Business (or enterprise) rules -- e.g., no one can receive a higher salary than the CEO.

ACID Transaction integrity (Lewis, et al) The transaction designer can assume the DB satisfies all integrity constraints before the transaction begins. The transaction, when completed, MUST leave the DB in a state where - (1) all integrity constraints are satisfied, and - (2) the new state reflects the transformation as specified.

ACID Ways to check integrity: - Some via SQL’s DDL (PRIMARY KEY, NOT NULL) - CHECK constraint (very time consuming because lots of unnecessary checking) - ASSERTION ( ditto ) - error checking within the transaction’s code. - increased vulnerability to programmer error - difficult to maintain as system spec changes

ACID A transaction is a unit of work. That is, a transaction does ALL the work required to ensure the DB is left in a consistent state.

ACID Atomicity (Lewis, et al) -- the system must ensure that either –the transaction completes, or –(if it doesn’t complete) it has no effect at all. Notice the difference from a task.

ACID Committed -- A transaction completes and the system guarantees to maintain its effect. Aborted -- A transaction does not complete, the system must undo any changes. Rolled back -- the operations the system takes to undo the effects of an aborted transaction.

Why might a transaction abort? System crash during execution. Transaction attempts a change that violates integrity. Transaction effects violate the ISOLATION requirement of ACID. Transaction involved in deadlock Transaction code has abort statement (error checking or debugging) Transaction responds to user initiated abort.

ACID Durability (Lewis, et al) -- Once a transaction commits, its effects remain in the DB, even if the computer or storage subsequently fails.

ACID Causes of failure - CPU crash - Disk failure - Multiple disk failures - External accidents (fire, EMP) - Malice

ACID Isolation is the property that each transaction’s effect on the data is correct, even when other executing transactions may be accessing the same data. Note the related meaning to interleaving tasks (critical section, re-entrancy, independence, mutexes, …)

ACID Serial execution -- one transaction commits before another transaction begins. Concurrent execution -- more than one transaction is active simultaneously (many active, partially completed (all uncommitted) transactions)

ACID A typical transaction will read a data element (“global”) into local variable, then do some processing on the local, then write a data element. The important thing to look at is the operations (the reads, writes and updates) on the data base. The operations of a serial transaction schedule will leave the DB in a consistent and correct state. Interleaving those same transactions may not.

ACID Isolation (Lewis, et al) -- when multiple transactions are executed concurrently, the final effect is as though the transactions had executed serially. Concurrent schedules that satisfy the isolation property are serializable.

Transaction Transistion State Diagram

Two phase commit protocol 2PC There is a coordinator ( C ) that knows the set of current transactions (by keeping track of current transaction control blocks) -- I.e., it is a bookkeeper. When a transaction requests commit, the 2PC begins (next slide). Any transaction can unilaterally abort. All must agree to commit.

2PC -- 2 rounds of messages: vote, then termination. C initiates vote phase; Sends prepare message to each active transaction. When an active receives a prepare, it decides whether to abort or commit. It sends no (abort) or yes (commit) message to C. C initiates termination phase; If C receives all yes messages, it sends commit message to all actives. If it receives one or more no (or no response), it sends abort to all actives. When transaction receives abort, it aborts. When it receives a commit, it commits.