Transation Management

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

© 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

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

© 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

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

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

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

Example: Simple Purchases If 1-2-3 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

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

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

summary