15368_lecture 34 to 36
Transcript of 15368_lecture 34 to 36
-
8/7/2019 15368_lecture 34 to 36
1/14
Transaction Concept A transactionis a unitof program
execution that accesses and possiblyupdates various data items.
E.g. transaction to transfer $50 fromaccount A to account B:1. read(A)
2. A := A 503. write(A)4. read(B)5. B := B + 506. write(B)
Two main issues to deal with:
Failures of various kinds, such as hardwarefailures and system crashes
Concurrent execution of multipletransactions
-
8/7/2019 15368_lecture 34 to 36
2/14
ACID Properties
Atomicity. Either all operations of the transaction areproperly reflected in the database or none are.
Consistency. Execution of a transaction in isolationpreserves the consistency of the database.
Isolation. Although multiple transactions may executeconcurrently, each transaction must be unaware of otherconcurrently executing transactions. Intermediatetransaction results must be hidden from other concurrentlyexecuted transactions. That is, for every pair of transactions Tiand Tj, it appears to Tithat
either Tj, finished execution before Ti started, or Tj startedexecution after Ti finished.
Durability. After a transaction completes successfully, thechanges it has made to the database persist, even if thereare system failures.
A transaction is a unit of program execution that accesses and possibly
updates various data items.To preserve the integrity of data the databasesystem must ensure:
-
8/7/2019 15368_lecture 34 to 36
3/14
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)
Atomicity requirement if the transaction fails after step 3 and before step 6, money will be lost
leading to an inconsistent database state
Failure could be due to software or hardware
the system should ensure that updates of a partially executed transactionare not reflected in the database
Consistency requirement in above example: the sum of A and B is unchanged by the execution of the transaction A transaction must see a consistent database. During transaction execution the database may be temporarily
inconsistent. When the transaction completes successfully the database must be
consistent
-
8/7/2019 15368_lecture 34 to 36
4/14
Example of Fund Transfer(Cont.) Durability requirement once the user has been notified
that the transaction has completed (i.e., the transfer of the$50 has taken place), the updates to the database by thetransaction must persist even if there are software orhardware failures.
Isolation requirement if between steps 3 and 6, anothertransaction T2 is allowed to access the partially updateddatabase, it will see an inconsistent database (the sum A + Bwill be less than it should be). T1 T2
1. read(A)
2. A := A 503. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)
-
8/7/2019 15368_lecture 34 to 36
5/14
Transaction State Active A transaction under execution. Partially committed A transaction
executing the last statement Failed -- after the discovery that normal
execution can no longer proceed.
Aborted after the transaction has beenrolled back and the database restored toits state prior to the start of thetransaction. Two options after it has beenaborted: restart the transaction
can be done only if no internal logical error kill the transaction
Committed after successful completion.
-
8/7/2019 15368_lecture 34 to 36
6/14
Transaction State
(Cont.)
Ex
ecuting
Successful
Execution
Fault
Fault
Roll Back
-
8/7/2019 15368_lecture 34 to 36
7/14
Implementation ofAtomicity and Durability
The recovery-management component of a databasesystem implements the support for atomicity and durability.
E.g. the shadow-database scheme:
all updates are made on a shadow copyof the database
db_pointer is made to point to the updated shadow copy
after the transaction reaches partial commit andall updated pages have been flushed to disk.
-
8/7/2019 15368_lecture 34 to 36
8/14
Implementation of Atomicity andDurability (Cont.)
db_pointer always points to the currentconsistent copy of the database. In case transaction fails, old consistent copy pointed to
by db_pointer can be used, and the shadow copy canbe deleted.
The shadow-database scheme: Assumes that only one transaction is active at a time. Assumes disks do not fail Useful for text editors, but
extremely inefficient for large databases (why?)
Variant called shadow paging reduces copying of data, butis still not practical for large databases
Does not handle concurrent transactions
-
8/7/2019 15368_lecture 34 to 36
9/14
Serializability Basic Assumption Each transaction preserves
database consistency. Thus serial execution of a set of transactions
preserves database consistency. A (possibly concurrent) schedule is serializable if it
is equivalent to a serial schedule. Different formsof schedule equivalence give rise to the notions of:1.conflict serializability2.view serializability
Simplified view of transactions We ignore operations other than read and write
instructions
We assume that transactions may perform arbitrarycomputations on data in local buffers in between readsand writes.
Our simplified schedules consist of only read and writeinstructions.
-
8/7/2019 15368_lecture 34 to 36
10/14
Conflicting Instructions Instructions li and lj of transactions Ti and Tj respectively,
conflict if and only if there exists some item Q accessed by
both li and lj, and at least one of these instructions wrote Q.1. li = read(Q), lj = read(Q). li and ljdont conflict. Since
the same value of Q is read by Ti and Tj
2. li = read(Q), lj = write(Q). They conflict. Ifli comes
befor e lj , then Ti does not read the value of Q that is written
by Tj in instruction lj.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
-
8/7/2019 15368_lecture 34 to 36
11/14
Conflict Serializability
If a scheduleS
can be transformedinto a schedule Sby a series ofswaps of non-conflictinginstructions, we say that S and S
are conflict equivalent. We say that a schedule S is conflict
serializable if it is conflict
equivalent to a serial schedule
-
8/7/2019 15368_lecture 34 to 36
12/14
Conflict Serializability(Cont.)
Schedule 3 can be transformed into Schedule 6, a
serial schedule where T2 follows T1, by series ofswaps of non-conflicting instructions.
Therefore Schedule 3 is conflict serializable.
Schedule 3 Schedule 6
-
8/7/2019 15368_lecture 34 to 36
13/14
View Serializability Let S and Sbe two schedules with the same set of
transactions. S and Sare view equivalentif thefollowing three conditions are met, for each data item Q,
1. If in schedule S, transaction Tireads the initial value ofQ, then in
schedule Salso transaction Ti must read the initial value ofQ.
2. If in schedule S transaction Tiexecutes read(Q), and that value
was produced by transaction Tj (if any), then in schedule Salso
transaction Ti
must read the value ofQ that was produced by the
same write(Q) operation of transaction Tj .
3. The transaction (if any) that performs the final write(Q) operationin schedule S must also perform the finalwrite(Q) operation inschedule S.
As can be seen, view equivalence is also based purely onreads and writes alone.
-
8/7/2019 15368_lecture 34 to 36
14/14
View Serializability
(Cont.) A schedule S is view serializableif it is view equivalent to
a serial schedule. Every conflict serializable schedule is also view serializable.
Below is a schedule which is view-serializable but notconflict serializable.
What serial schedule is above equivalent to?
Every view serializable schedule that is not conflictserializable has blind writes.