1. Transactions and Wrap-Up
Zachary G. Ives
University of Pennsylvania
CIS 550 – Database & Information Systems
December 6, 2009
Some slide content derived from Ramakrishnan & Gehrke

2. Reminders Please be sure you’re signed up for a project demo
Due with the project demo: the project code (.zipped via )
Due by 12/22: page report describing:
What your project goals were
What you implemented
Basic architecture and design
Division of labor
Also: please me an assessment of your group; group members’ contributions; your contributions
Midterm on Wednesday OR final exam on 12/22

3. Recall – Lack of Isolation: Dirty Reads
Dirty data is data written by an uncommitted transaction; a dirty read is a read of dirty data (WR conflict)
Sometimes we can tolerate dirty reads; other times we cannot:
e.g., if we wished to ensure balances never went negative in the transfer example, we should test that there is enough money first!

4. “Bad” Dirty Read If the initial read (italics) were dirty, the balance
EXEC SQL select balance into :bal
from Accounts
where account#=‘1234’;
if (bal > 100) {
EXEC SQL update Accounts
set balance = balance - $100
where account#= ‘1234’;
set balance = balance + $100
where account#= ‘5678’; }
EXEC SQL COMMIT;
If the initial read (italics) were dirty, the balance
could become negative!

5. Acceptable Dirty Read
If we are just checking availability of an airline seat, a dirty read might be fine! (Why is that?)
Reservation transaction:
EXEC SQL select occupied into :occ
from Flights
where Num= ‘123’ and date=
and seat=‘23f’;
if (!occ) {EXEC SQL
update Flights
set occupied=true
and seat=‘23f’;}
else {notify user that seat is unavailable}

6. Other Undesirable Phenomena
Unrepeatable read: a transaction reads the same data item twice and gets different values (RW conflict)
Phantom problem: a transaction retrieves a collection of tuples twice and sees different results

7. Phantom Problem Example
T1: “find the students with best grades who Take either cis550-f09 or cis570-f08”
T2: “insert new entries for student #1234 in the Takes relation, with grade A for cis570-f08 and cis550-f09”
Suppose that T1 consults all students in the Takes relation and finds the best grades for cis550-f09
Then T2 executes, inserting the new student at the end of the relation, perhaps on a page not seen by T1
T1 then completes, finding the students with best grades for cis570-f08 and now seeing student #1234

8. Isolation The problems we’ve seen are all related to isolation
General rules of thumb w.r.t. isolation:
Fully serializable isolation is more expensive than “no isolation”
We can’t do as many things concurrently (or we have to undo them frequently)
For performance, we generally want to specify the most relaxed isolation level that’s acceptable
Note that we’re “slightly” violating a correctness constraint to get performance!

9. Specifying Acceptable Isolation Levels
The default isolation level is SERIALIZABLE (as for the transfer example).
To signal to the system that a dirty read is acceptable,
In addition, there are
SET TRANSACTION READ WRITE
ISOLATION LEVEL READ UNCOMMITTED;
SET TRANSACTION
ISOLATION LEVEL READ COMMITTED;
ISOLATION LEVEL REPEATABLE READ;

10. READ COMMITTED
Forbids the reading of dirty (uncommitted) data, but allows a transaction T to issue the same query several times and get different answers
No value written by T can be modified until T completes
For example, the Reservation example could also be READ COMMITTED; the transaction could repeatably poll to see if the seat was available, hoping for a cancellation

11. REPEATABLE READ
What it is NOT: a guarantee that the same query will get the same answer!
However, if a tuple is retrieved once it will be retrieved again if the query is repeated
For example, suppose Reservation were modified to retrieve all available seats
If a tuple were retrieved once, it would be retrieved again (but additional seats may also become available)

12. Implementing Isolation Levels
One approach – use locking at some level (tuple, page, table, etc.):
each data item is either locked (in some mode, e.g. shared or exclusive) or is available (no lock)
an action on a data item can be executed if the transaction holds an appropriate lock
consider granularity of locks – how big of an item to lock
Larger granularity = fewer locking operations but more contention!
Appropriate locks:
Before a read, a shared lock must be acquired
Before a write, an exclusive lock must be acquired

13. Lock Compatibility Matrix
Locks on a data item are granted based on a lock compatibility matrix:
When a transaction requests a lock, it must wait (block) until the lock is granted
Mode of Data Item
None Shared Exclusive
Shared Y Y N
Exclusive Y N N
Request mode {

14. Locks Prevent “Bad” Execution
If the system used locking, the first “bad” execution could have been avoided:
Deposit Deposit 2
xlock(X)
read(X.bal)
{xlock(X) is not granted}
X.bal := X.bal + $50
write(X.bal)
release(X)
X.bal:= X.bal + $10

15. Lock Types and Read/Write Modes
When we specify “read-only”, the system only uses shared-mode locks
Any transaction that attempts to update will be illegal
When we specify “read-write”, the system may also acquire locks in exclusive mode
Obviously, we can still query in this mode

16. Isolation Levels and Locking
READ UNCOMMITTED allows queries in the transaction to read data without acquiring any lock
For updates, exclusive locks must be obtained and held to end of transaction
READ COMMITTED requires a read-lock to be obtained for all tuples touched by queries, but it releases the locks immediately after the read
Exclusive locks must be obtained for updates and held to end of transaction

17. Isolation levels and locking, cont.
REPEATABLE READ places shared locks on tuples retrieved by queries, holds them until the end of the transaction
Exclusive locks must be obtained for updates and held to end of transaction
SERIALIZABLE places shared locks on tuples retrieved by queries as well as the index, holds them until the end of the transaction
Holding locks to the end of a transaction is called “strict” locking

18. Summary of Isolation Levels
Level Dirty Read Unrepeatable Read Phantoms
READ UN- Maybe Maybe Maybe
COMMITTED
READ No Maybe Maybe
REPEATABLE No No Maybe
READ
SERIALIZABLE No No No

19. Locking and Serializability
A transaction must hold all locks until it terminates (a condition called strict locking)
It turns out that this is crucial to guarantee serializability
Note that the first (bad) example could have been produced if transactions acquired and immediately released locks.

20. Questions to Address Given a schedule S, is it serializable?
How can we "restrict" transactions in progress to guarantee that only serializable schedules are produced?

21. Conflicting Actions
Consider a schedule S in which there are two consecutive actions Ii and Ij of transactions Ti and Tj respectively
If Ii and Ij refer to different data items, then swapping Ii and Ij does not matter
If Ii and Ij refer to the same data item Q, then swapping Ii and Ij matters if and only if one of the actions is a write
Ri(Q) Wj(Q) produces a different final value for Q than Wj(Q) Ri(Q)

22. Testing for Serializability
Given a schedule S, we can construct a di-graph G=(V,E) called a precedence graph
V : all transactions in S
E : Ti  Tj whenever an action of Ti precedes and conflicts with an action of Tj in S
Theorem: A schedule S is conflict serializable if and only if its precedence graph contains no cycles
Note that testing for a cycle in a digraph can be done in time O(|V|2)

23. An Example T1 T2 T3 R(X,Y,Z) R(X) W(X) R(Y) W(Y) W(Z) T1 T2 T3
Cyclic: Not serializable.

24. Another Example T1 T2 T3 R(X) W(X) T1 T2 T3 R(Y) W(Y)
Acyclic: serializable

25. Producing the Equivalent Serial Schedule
If the precedence graph for a schedule is acyclic, then an equivalent serial schedule can be found by a topological sort of the graph
For the second example, the equivalent serial schedule is:
R1(Y)W1(Y)R2(X)W2(X) R2(Y)W2(Y) R3(X)W3(X)

26. Locking and Serializability
We said that a transaction must hold all locks until it terminates (a condition called strict locking)
It turns out that this is crucial to guarantee serializability
Note that the first (bad) example could have been produced if transactions acquired and immediately released locks.

27. Well-Formed, Two-Phased Transactions
A transaction is well-formed if it acquires at least a shared lock on Q before reading Q or an exclusive lock on Q before writing Q and doesn’t release the lock until the action is performed
Locks are also released by the end of the transaction
A transaction is two-phased if it never acquires a lock after unlocking one
i.e., there are two phases: a growing phase in which the transaction acquires locks, and a shrinking phase in which locks are released

28. Two-Phased Locking Theorem
If all transactions are well-formed and two-phase, then any schedule in which conflicting locks are never granted ensures serializability
i.e., there is a very simple scheduler!
However, if some transaction is not well-formed or two-phase, then there is some schedule in which conflicting locks are never granted but which fails to be serializable
i.e., one bad apple spoils the bunch

29. Summary
Transactions are all-or-nothing units of work guaranteed despite concurrency or failures in the system
Theoretically, the “correct” execution of transactions is serializable (i.e. equivalent to some serial execution)
Practically, this may adversely affect throughput  isolation levels
With isolation levels, users can specify the level of “incorrectness” they are willing to tolerate

30. What to Look for Down the Road
Well, no one really knows the answer to this…
But here are some current directions:
Sensors, networks, and streaming data
Peer-to-peer meets databases and data integration
“The Semantic Web”
Security and privacy – especially as integration becomes more commonplace
Uncertainty and ranked retrieval
… We have lots of research projects at Penn relating to these and other topics

31. A Plug for Next Year CIS 455/555 (Spring): Internet and Web Systems
Focus: building and interconnecting scalable Web servers and services; information retrieval; integration; cloud computing
Emphasis on implementation, programming-in-the-large, experimentation – need substantial coding experience
Meanwhile… Best of luck on your projects and exams – and have a wonderful break!
I hope you learned a lot in this course and that it was enjoyable!