1. Atomic Tranactions. Sunmeet Sethi

2. Index  Meaning of Atomic transaction.  Transaction model Types of storage. Transaction primitives. Properties of transactions. Nested transaction  Implementation Private workspace Writeahead lock  Two phase commit protocol  Concurrency control Locking Optimistic concurrency control Timestamps  Refrences:

3. Atomic Transaction. what does it mean???  All or Nothing  Either the transaction is committed or aborted.  Original Model comes from the world of business.  If transaction is completed the results are made permanent and if not we are back at the state where we were before the transaction began.  Example: Transfer of funds in a bank.

4. Transaction Model.  The traditional transaction model was originally developed for data processing applications.  Types of storage.  Transaction primitives.  Properties of transactions.  Nested transaction.

5. Types of storage. 3 Types  Random Access Memory  Disk Storage  Stable Storage  RAM Storage wipes out when power fails or machine crashes.  Disk Storage Survives CPU failure but data is lost when disk crashes.  Stable Storage survives anything except major calamities.Most Suitable for atomic transaction as high degree of fault tolerence

6. Stable Storage.  Implemented with a pair of disks.  Each block on drive 2 is exact copy of corresponding block of drive 1.  When a block is updated,first the block on disk 1 is updated and verified and then corresponding block on disk 2 is updated.  PROBLEMS  What if system 1 crahses after it is updated BUT before Disk 2 is updated??  Spontaneous decay of Block. Dust or general wear & tear can cause checksum error without warning.In this case bad block is regenerated from the corresponding block on the other side.

7. Transaction Primitives.  BEGIN_TRANSACTION: Mark ths start of transaction.  END_TRANSACTION: Terminate the transaction and try to commit.  ABORT_TRANSACTION: Kill the transaction and restore the old values  READ: Read data from the file.  WRITE: Write data to the file.  Others:: Send, Receive, forward etc.

8. Transaction Primitives(Cont..)  Depends upon what kind of object are being used.  BEGIN_TRANSACTION and END_TRANSACTION are used to delimit the scope of a transaction.  The operation between them form the body of transaction  Body:: system calls, library procedures, brackets etc.  Either all of them are executed or none of them is executed.

9. Example of Transaction Primitives  Flight from Atlanta to canada.  Atlanta  NY  Canada BEGIN_TRANSACTIONBEGIN_TRANSACTIONReserve Atl-NY Reserve NY-CaReserve NY-Ca-FULL END_TRANSACTIONEND_TRANSACTION (a) (b) Transaction A will be commited but transaction B will be aborted as there is no flight available from New york to Canada.

10. Properties of a transaction.  ACID properties.  Atomic: transaction happens indivisibly  Consistent: does not violate systems invariants.  Isolated: concurrent transactions do not interfere with each other.  Durable: once Committed changes are permanent.

11. Atomicity  Each transaction either happens completely or not at all AND if it happens no one can see any of the intermediate states.  Transaction executes in a single indivisible instantaneous action.  Example : A file of 10 bytes.

12. Consistency  The transaction does not violate system invariants.  If there are invariants that must hold on a system  If they held before the transaction started they will be held after the transaction.  Example: internal transfer of funds in a bank.

13. Isolation  If 2 or more transactions run at same time  To each of them and to other processes, the final result looks as though all transactions ran in some sequential order.  Result basically depend upon the scheduling property of system.

14. Durability  Once the transaction is committed, there is no way to go back and undo the results  The effect become permanent once transaction is completed.  No failure can undo the results or cause them to lost.

15. Nested Transaction  Transaction may contain sub transactions  Example: A process can fork() a child and this child can further fork a child() to improve performance or simplifying programming.  Problem: what if parent aborts before child??  Considerable administration is needed to get everything right of the track.

16. Implementation  Private Work Place  Writeahead Log

17. Private work place  Each process is given its own private work place which contains all the files and objects which the process needs during execution before transaction can start.  Until transaction commits OR aborts all the reads and writes go to private workspace  Once the transaction is committed, changes are made to real objects and files.  Problem:: Cost

18. Private workspace (cont…)  Optimizations::  If a process wants to just read the file not to update or change anything, then there is no need to copy the file in process workspace.  If process wants to write to a file, then instead of copying entire file in private workspace, only the file’s index is copied.  Index: block of data which points where the each block of file is located in the memory.  When a block of file is changed, the copy is made and the address of that copy is updated into the in dex table. These new blocks are called shadow blocks.

19. Writeahead log  Also called intentions list  Before any block of a file is changed, an entry is made into the log table which is stored on stable storage.  Log table indicates which transaction is making change Which block of a file is being changed What the old and new values are? Only after log is written successfully, changes are made to the file

20. Example of writeahead A=0; B=0; LOG BEGIN_TRANSACTION Log A=A+1; B=B+1; END_TRANSACTION Log can be used for recovering from crashes using roll back. A=0/1 B=0/1

21. Two Phase commit protocol  Process that start transaction becomes coordinator  Coordinator writes a log entry stating that it is going to commit and sends messages to each of the involved process.  Each involved process checks whether it is ready to commit or not  If yes then it create a log entry and sends back to coordinator  Depending upon the responses from each of the involved processes, transaction is either committed or aborted.  Either way coordinator informs the involved processes of the decision.

22. Concurrency control  Means of keeping the multiple transactions out of each other.  Three different ways of concurrency control Locking Optimistic concurrency control Timestamps

23. Locking  Oldest and most widely used algo.  When process needs to read or write a file, it first locks the file.  Lock manager maintains the list of all locked files.  Once a file is locked, no other process can use the file  This ensures that file has not changed during the entire execution of transaction.

24. Locking(cont…)  Two types of locks Read Locks: shared write locks: Exclusive  Granularity of a lock:: means wat size can be locked eg. Entire book or chapter or single page  Finer the granularity more precise is the lock.

25. Two phase locking  Growing phase  Shrinking phase  If process is unable to acquire any of the lock, it releases all the locks and try again later.  Strict-Two Phase locking:  Shrinking phase does not occur until transaction has committed or aborted  2 Advantages :: a) transaction always reads a values written by committed transactions b) all locks are acquired by the system without transaction being aware. c) NO cascaded aborts.  Disadvantage of Locking:Deadlocks

26. Optimistic concurrency control  Keep track of which files have been read or written.  During committing it checks all other transactions if any of the files have been changed during transaction.  If yes transaction is aborted, otherwise committed.  Advantages:: Deadlock Free Algorithm. Allow maximum parallelism.

27. Timestamps  Each file has read and write timestamp associated with it.  Every timestamp value is unique and accurately represents an instant in time. No two timestamps can be the same.  Every object is given a read timestamp and a write timestamp.  If a transaction wants to read an object,  but the transaction started before the object's write timestamp it means that something changed the object's data after the transaction started. In this case, the transaction is cancelled and must be restarted.  and the transaction started after the object's write timestamp, it means that it is safe to read the object. In this case, if the transaction timestamp is after the object's read timestamp, it is set to the transaction timestamp.

28. Timestamps(cont…)  If a transaction wants to write to an object,  but the transaction started before the object's read timestamp it means that something has had a look at the object, and we assume it took a copy of the object's data. So we can't write to the object as that would make any copied data invalid so the transaction is aborted and must be restarted.  and the transaction started before the object's write timestamp it means that something has changed the object since we started our transaction. In this case we simply cancel our transaction and continue as normal; it does not have to be restarted.  otherwise, the transaction writes to the object, and the object's write timestamp is set to the transaction's timestamp.

29. Refrences  Distributed Operating systems,Tanenbaum.  Operating systems design n implemntation, tanenbaum.