Transaction and concurrency controll

1. Transaction and concurrencycontroll Chapter 13 “Distributed Systems: Concepts and Design” Coulouris, Dollimore, Kindberg Hanna Björling, Stina Fröjd & Liv Sundman

2. Transaction • A transaction is a point where there is interaction with the database • A transaction is generally atomic • The state of the transaction being done is not visible. If it is not done completely, any changes it made will be undone. This is known as rollback

3. Transaction • It’s common to talk about transactions in banking systems • Ex: A transfer between accounts. The money should be transferred as well as withdrawn • To make sure both things are done concurrency control is used

4. Concurrencycontrol • Concurrency – multiple users want to access the same data at the same time • Concurrency control (CC) ensures that correct results for parallel operations are generated • CC provides rules, methods, design methodologies and theories to maintain the consistency of components operating simultaneously while interacting with the same object

5. Whyconcurrencycontrol? • Concurrency control is needed because there are a lot of things that can go wrong • Each transaction itself can be okay, but the concurrency generates problems such as: • The lost update problem • The dirty read problem • The incorrect summary problem

6. Read and writeconflicts Figur 13.9

7. Three methods • There are many methods for concurrency control • The main methods are: • Locks • Optimistic concurrency control • Timestamp ordering

8. Locks • Locks are used to order transactions that access the same objects according to the order of arrival of their operations at the objects • Mechanism for enforcing limits on access to the object • If the access to the object is locked other users have to wait until it’s unlocked

9. Lock compability Figur 13.15

10. Held by Waits for A T U U T B Waits for Held by A problem with lock • The use of locks can lead to deadlocks • Ex: Two transactions are waiting and each is dependent on the other to release a lock so it can resume Figur 13.20

11. Optimistic concurrency control • Optimistic concurrency control (OCC) is based on the assumption that two transactions won’t occur at the same time • OCC is generally used in environments with low data contention

12. OCC phases • Begin • Workingphase • Validationphase • Updatephase

13. OCC phases • Begin: Record a timestamp marking the transaction's beginning • Working phase: Read and write database values to a copy of the transaction which is not yet bound to the object. Several different transactions of this type may coexist

14. OCC phases • Validate phase: Controls if the transaction conflicts with another transaction on the same object • Update phase: • Committed: If there is no conflict, make all changes part of the official state of the database • Aborted: If there is a conflict, resolve it, typically by aborting the transaction, although other resolution schemes are possible

15. Timestamp • Whenever a transaction starts, it is given a timestamp • The timestamp tells in which order that the transactions are supposed to be applied in • The transaction with the earliest timestamp is executed first • Every object in the database has a read timestamp and a write timestamp

16. Major goals • Serializability • Recoverability • Distribution

17. Serializability • The goal with serializability is that the result of the parallel transactions is the same as if though the transactions were preformed serially

18. Recoverability • Recoverability means that committed transactions do not read data written by aborted transactions

19. distribution • Distributed serializability • The serializability concept Commitment Ordering allows to effectively achieve global serializability across multiple Database Systems, that may use different concurrency control mechanisms.

20. Questions?

21. Thank you,Nu är det slut!