1. Transation Management

2. © Dennis Shasha, Philippe Bonnet 2001
overview
© Dennis Shasha, Philippe Bonnet 2001

3. © Dennis Shasha, Philippe Bonnet 2001
Lock Tuning
1. Use special system facilities for long reads.
2. Eliminate locking when it is unnecessary.
3. Take advantage of transactional context to chop transactions into small pieces.
4. Weaken isolation guarantees when the application allows it.
5. Select the appropriate granularity of locking.
6. Change your data description data during quiet periods only. (Data Definition Language statements are considered harmful.)
7. Think about partitioning.
8. Circumvent hot spots.
9. Tune the deadlock interval.
© Dennis Shasha, Philippe Bonnet 2001

4. Use facilities for long reads
Oracle provides snapshot isolation, whereby read-only queries hold no locks yet appear to execute serializably
A read-only transaction R reads the database as the database appeared when R began
© Dennis Shasha, Philippe Bonnet 2001

5. © Dennis Shasha, Philippe Bonnet 2001
Snapshot isolation
Read-only queries suffer no locking overhead.
Read-only queries can execute in parallel and on the same data as short update transactions without causing blocking or deadlocks.
When extended to read/write transactions, snapshot isolation does not guarantee correctness
For example: T1 : x := y T2 : y := x
The lesson is: use snapshot isolation for read-only transactions
© Dennis Shasha, Philippe Bonnet 2001

6. Eliminate unnecessary locking
Locking is unnecessary in two cases.
1. When only one transaction runs at a time, for example, when loading the database
2. When all transactions are read-only, for example, when doing decision support queries on archival databases
© Dennis Shasha, Philippe Bonnet 2001

7. Make your transaction short
How long should a transaction be?
The more locks a transaction requests, the more likely it is that it will have to wait for some other transaction to release a lock.
The longer a transaction T executes, the more time another transaction will have to wait if it is blocked by T.
© Dennis Shasha, Philippe Bonnet 2001

8. Example: Simple Purchases
Purchase item I for price P
If cash < P then roll back transaction (constraint)
Inventory(I) := inventory(I)+P
Cash := Cash – P
Two purchase transaction P1 and P2
P1 has item I for price 50
P2 has item I for price 75
Cash is 100
© Dennis Shasha, Philippe Bonnet 2001

9. Example: Simple Purchases
If as one transaction then one of P1, P2 rolls back.
If 1, 2, 3 as three distinct transactions:
P1 checks that cash > 50. It is.
P2 checks that cash > 75. It is.
P1 completes. Cash = 50.
P2 completes. Cash = - 25.
© Dennis Shasha, Philippe Bonnet 2001

10. Example: Simple Purchases
Orthodox solution
Make whole program a single transaction
Cash becomes a bottleneck!
Chopping solution
Find a way to rearrange and then chop up the transactions without violating serializable isolation level.
© Dennis Shasha, Philippe Bonnet 2001

11. Example: Simple Purchases
Chopping solution:
If Cash < P then roll back. Cash := Cash – P.
Inventory(I) := inventory(I) + P
Chopping execution:
P11: 100 > 50. Cash := 50.
P21: 75 > 50. Rollback.
P12: inventory := inventory + 50.
© Dennis Shasha, Philippe Bonnet 2001

12. summary