Transactions. ACID Properties of Transactions. Atomicity - all or nothing property - Fully performed or not at all

Transcription

1 Transactions - An action, or series of actions, carried out by a single user or application program, which reads or updates the contents of the database - Logical unit of work on the database - Usually begins with an SQL statement (SELECT, INSERT, UPDATE, DELETE, ) - Consists of one or more SQL statements grouped together as one logical unit of work - Changes made not visible to others until transaction completes Transaction can have one of two outcomes - Committed o completes successfully and database transformed to a new consistent state o Committed transaction cannot be aborted Can only perform compensating transaction to reverse its effects - Aborted fails to complete successfully and database restored to previous consistent state Completes when either - COMMIT statement ends successfully - ROLLBACK statement aborts transaction, backing out any changes - Successful program termination (even without COMMIT) - Abnormal program termination (aborts transaction and ROLLBACK performed) - SQL-session terminated (COMMITs) ACID Properties of Transactions Atomicity - all or nothing property - Fully performed or not at all Consistency - Transform database from one consistent state to another - DBMS enforces all integrity constraints - Responsibility of application developers to ensure consistency (money b/w accounts) Isolation - Execute independently of other transactions - Partial effects are not visible to others - Responsibility of concurrency control system Durability - Results of committed transaction permanently recorded in database - Recovery system must ensure durability

2 Concurrency Control - The process of managing simultaneous operations on the database without having them interfere with one another - Two or more users (or applications) are accessing database simultaneously and at least one is updating data - Interleaving of operations in transactions may produce incorrect results Three potential problems - Lost update problem - Uncommitted dependency problem - Inconsistent analysis problem Lost Update Problem - Successfully completed update is overridden by another user - Must prevent T1 from reading balance until after T2 updates since T2 reads first Uncommitted Dependency Problem - One transaction sees intermediate results of another before it has committed - Must prevent T3 from reading balance until after T4 commits or aborts

3 Inconsistent Analysis Problem - One transaction reads several values but another updates them during execution of first - Referred to as a dirty read - Must prevent T6 from reading balx and balz until after T5 completes updates Schedule - A sequence of the operations of a set of concurrent transactions that preserves the order of the operations in each transaction Serial Schedule - A schedule where the operations of each transaction are executed consecutively without any interleaved operations from other transactions - No guarantee that the results of all serial executions of given set of transactions will be identical e.g. calculate interest before or after a large withdrawl Non-serial Schedule - A schedule where the operations from a set of concurrent transactions are interleaved Serializability - The equivalence of a non-serial schedule of transactions to some serial schedule of them - Objective is to find a non-serial schedule that permits the transactions to execute concurrently without interfering with one another, thus producing a database state that could be produced by some serial execution of the transactions - Ordering of read and write operations is important o If two transactions only read a data item, order is not important o If two transactions either read or write completely separate data items, order is not important o If one transaction writes a data item and another either reads or writes the same data item, the order of execution is important

4 Conflict Serializability - Any conflicting operations are ordered in the same way as some serial execution - (c) contains a serial schedule that is equivalent to both (a) and (b) Testing for conflict serializability - Constrained write rule o Transaction updates data item based on its old value, which is first read - Precedence Graph o Node for each transaction o Edge from node that writes a value to node that then reads that same value o Edge from node that reads a value to a node that then writes into that same item o Presence of cycle indicates schedule is not conflict serializable

5 View Serializability - Less restrictive definition of serializability - Two schedules are view equivalent if: o If one transaction reads the initial value of an item in one schedule, then it reads the initial value of that item in the other o If one transaction reads a value written by another in one schedule, then it reads that value of that item in the other o For each data item, if the last write operation of it is performed by some transaction in one schedule, the same transaction must perform the last write in the other Every conflict serializable schedule is view equivalent to a serial schedule, and thus view serializable, although the converse is not true (it can be shown that if it isn t, then some transaction performs blind writes writes without reads Testing for view serializability is NP-Complete Recoverable Schedule - A schedule where, for each pair of transactions, if one reads a data item previously written by the other, then the commit operation of the other precedes the commit operation of the one - If second transaction fails to commit, then first cannot be permitted to commit