Professional Documents
Culture Documents
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.dbbook.com for conditions on reuse
Chapter 15: Transactions
■ Transaction Concept
■ Transaction State
■ Concurrent Executions
■ Serializability
■ Recoverability
■ Implementation of Isolation
■ Transaction Definition in SQL
■ Testing for Serializability.
– e.g. sum of balances of all accounts, minus sum of loan amounts
must equal value of cashinhand
● 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
Erroneous transaction logic can lead to inconsistency
■ db_pointer always points to the current consistent copy of the database.
● In case transaction fails, old consistent copy pointed to by db_pointer
can be used, and the shadow copy can be deleted.
■ The shadowdatabase 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, but is
still not practical for large databases
● Does not handle concurrent transactions
■ Will study better schemes in Chapter 17.
• A serial schedule where T2 is followed by T1
Schedule 3 Schedule 6
Database System Concepts 5th Edition, Oct 5, 2006. 15.21 ©Silberschatz, Korth and Sudarshan
Conflict Serializability (Cont.)
■ Example of a schedule that is not conflict serializable:
■ We are unable to swap instructions in the above schedule to obtain
either the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.
■ What serial schedule is above equivalent to?
■ Every view serializable schedule that is not conflict serializable has
blind writes.
■ Determining such equivalence requires analysis of operations
other than read and write.
T1 T2
T3
T4 T5
read(X)
read(Y)
read(Z)
read(V)
read(W) T1 T2
read(W)
read(Y)
write(Y)
write(Z)
read(U)
read(Y)
T3 T4
write(Y)
read(Z)
write(Z)
read(U)
write(U) T5
■ If T8 should abort, T9 would have read (and possibly shown to the user)
an inconsistent database state. Hence, database must ensure that
schedules are recoverable.
If T10 fails, T11 and T12 must also be rolled back.
■ Can lead to the undoing of a significant amount of work
■ Concurrencycontrol protocols allow concurrent schedules, but ensure
that the schedules are conflict/view serializable, and are recoverable
and cascadeless .
■ Concurrency control protocols generally do not examine the
precedence graph as it is being created
● Instead a protocol imposes a discipline that avoids nonseralizable
schedules.
● We study such protocols in Chapter 16.
■ Different concurrency control protocols provide different tradeoffs
between the amount of concurrency they allow and the amount of
overhead that they incur.
■ Tests for serializability help us understand why a concurrency control
protocol is correct.
■ Lower degrees of consistency useful for gathering approximate
information about the database
■ Warning: some database systems do not ensure serializable
schedules by default
● E.g. Oracle and PostgreSQL by default support a level of
consistency called snapshot isolation (not part of the SQL
standard)
Database System Concepts 5th Edition, Oct 5, 2006. 15.36 ©Silberschatz, Korth and Sudarshan
Transaction Definition in SQL
■ Data manipulation language must include a construct for
specifying the set of actions that comprise a transaction.
■ In SQL, a transaction begins implicitly.
■ A transaction in SQL ends by:
● Commit work commits current transaction and begins a new
one.
● Rollback work causes current transaction to abort.
■ In almost all database systems, by default, every SQL statement
also commits implicitly if it executes successfully
● Implicit commit can be turned off by a database directive
E.g. in JDBC, connection.setAutoCommit(false);
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.dbbook.com for conditions on reuse
Database System Concepts 5th Edition, Oct 5, 2006. 15.39 ©Silberschatz, Korth and Sudarshan
Database System Concepts 5th Edition, Oct 5, 2006. 15.40 ©Silberschatz, Korth and Sudarshan
Schedule 7