1 Transactions Chapter

2 Transactions A transaction is: a logical unit of work a sequence of steps to accomplish a single task Can have multiple transactions executing at the same time

3 Example Suppose we have a database containing 4 relations: Employees, Computer, Software packages, PCs –Where PC is the relationship between Employee and Computer (desktop, laptops, etc.) –Employees contains a field with the total value of the software installed on his/her PC (softval) –Software contains the number of instances (numinst) of each package installed

4 Example cont’d If a user wants to add a new PC for an employee the following steps must be done: –add a tuple to Computer –add cid and eid to PC –increment numinst of SW for all SW installed –Add sid and increment softval column in Employee

5 Problems What if the softval is updated, but the numinst is not incremented? Should complete all of the above steps or none How to indicate all of the above is considered to be a single transaction? Begin Transaction End Transaction statements (see later text for Oracle info)

6 ACID property A tomicity C onsistency I solation D urability

7 Atomicity Atomicity: A transaction’s change to the state are atomic: either all happens or none happens. –If a problem occurs before the end of a transaction, DBMS must undo all changes since begin transaction abort the transaction (rollback) –If the transaction can be completed, commit the transaction

8 Atomicity cont’d Once a transaction is committed, any user accessing the DB should see new changes If a transaction is aborted, no one sees any changes

9 Consistency Consistency: A transaction is a correct transformation of the state. The action taken as a group does not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.

10 Isolation Isolation: Even though transactions execute concurrently, it appears to each transaction, T, that others executed either before T or after T, but not both

11 Durability Durability: Once a transaction completes successfully (commits), its changes to the state survive failures.

12 Concurrent access Suppose 2 users are updating the same employee record (Bob) Tom adds $50 worth of SW Mary deletes $50 worth of SW

13 Lost update (aka Dirty Write) First, both read in Bob’s current softval of $500 –Tom adds $50, writes softval = $550 –Mary deletes $50, writes softval = $450 or –Mary deletes $50, writes softval = $450 –Tom add $50, writes softval = $550 Either way, we have a lost update! The result should be $500

14 Solutions Permit only 1 transaction to update same data item at a time Can still allow multiple retrievals (reads) Still allow transactions to update different data items at the same time How is this done? –Concurrency Control – locking and optimistic

15 Locks 1.Lock employee's record until Tom updates, (Mary must wait) 2. Release locks, 3. Mary acquires lock and then can update

16 Locks Two kinds of locks shared lock (read-lock) exclusive lock (write-lock for updates) –multiple share locks can be assigned –only one exclusive lock can be assigned and it conflicts with a share lock –only one person can be updating the data, –but if no one is updating, multiple readers can read the data

17 Locks example Tom write-lock (X); read-item (X); X:=X+50; write-item (X); unlock (X); Mary write-lock (X); must wait -- read-item (X); X:=X-50; write-item (X); unlock (X);

18 Another locks example T1 write-lock (Z); read-item(Z); Z=Z-2 write-item(Z); unlock (Z); write-lock (X); read-item (X); X:=X-3; write-item (X); unlock (X); T2 write-lock(W): read-lock (Z); read-item (Z); read-lock (X); read-item (X); W:=X+Z; unlock (X); unlock (Z); Z unlocked T2 blocked waiting for Z Z unlocked T2 proceeds

Locks Previous example violates serialization (isolation) –Serialization – means interleaved result is equivalent to SOME serial order, e.g. T1 executed before T2 or T2 executed before T1 Need more than just locks Need Two-phase locking – 2PL 19

20 Two-Phase Lock (2PL) 2PL is a solution that : Request Lock before read or write Wait until no conflict Growing phase - request locks Shrinking phase - release locks – Once any lock is released, cannot request another lock – Commercial systems usually release all locks when transaction commits

21 Same Lock example T1 write-lock (Z); read-item(Z); Z=Z*2 write_item(Z); write-lock (X); read-item (X); X:=X*3; write-item (X); unlock (Z); unlock (X); T2 write-lock(W): read-lock (Z); read-item (Z); read-lock (X); read-item (X); W:=X+Z; unlock (X); unlock (Z); T2 blocked waiting for Z Z unlocked T2 proceeds X, Z unlocked

22 Another Lock Example T1 read-item (E); write-item(S) T2 read-item (S); write-item (E);

23 Lock Example T1 read-lock (E); read-item (E); write-lock (S); must wait -- T2 read-lock (S); read-item (S); write-lock (E); must wait -- T1 blocked waiting for S T2 blocked waiting for E

24 Problems with 2PL? T1 updates Employee table and has it locked T2 updates the Software table and has it locked T1 wants to update the Software table and requests the lock T2 wants to update the Employee table and requests lock both are waiting for tables the other one has locked -- Deadlock!

25 Solutions for deadlock Can prevent deadlock by: –locking all data will need at beginning –locking tables in a specific order Detect if deadlock has occurred (use a waits-for-graph or a time-out) and choose to abort one of the transactions

26 Lock Example T1 Read-lock(E) Write-lock(S) read-item (E) write-item(S) T2 Read-lock (S) Write-lock(E) read-item (S) write-item (E)

27 Some common types of 2PL Conservative 2PL – each transaction predeclare its readset and writeset. Although it doesn’t deal with deadlock most commercial 2PL systems use: –Strict 2PL – all of a transaction’s locks are release only after it commits or aborts. Oracle doesn’t guarantee serializability (isolation) unless request it

28 Lock granularity Lock granularity can have an impact on concurrency: – table, block or page, record, field the larger the granule, the easier, but less concurrency Oracle –doesn't lock for select –uses graphs and time-out –locking granularity is row level

29 Transactions in Oracle Transaction begins with first executable SQL statement. Transaction ends: –with commit, rollback (with or without release option). –with an alter, create or grant (issues automatic commit before and after executing). –with system failure or session stop unexpectedly (rollback)

30 Transactions in Oracle COMMIT WORK RELEASE makes all changes so far in transaction permanent ROLLBACK WORK RELEASE undoes all changes in transaction Can set a savepoint to rollback to: SAVEPOINT savepoint_name that can ROLLBACK TO savepoint_name

Optimistic Strategy Alternatives to locking? Updates are applied to local copies of the data (transaction workspace) If R/W conflicts OK, transactions are committed The DB is updated from local copies Otherwise transaction is aborted and restarted

Validation Concurrency Control Techniques (or certification) Optimistic (validation) Concurrency Control Techniques (or certification) In other concurrency control techniques, checking is done to the DB before operations are executed –2PL In optimistic, checking is done after

Optimistic 3 phases: 1.R phase - Read items from DB, updates to local copies 2. validation phase - check for R/W conflicts 3. W phase – if validation successful, update DB else, restart transaction

Optimistic This protocol uses timestamps and W-sets and R-sets If transactions typically access different data items, transactions validated successfully and optimistic protocol works well else it doesn't and locking is better

35 Summary Interleave transactions Correctness: ACID Serial schedule is correct Serializable schedule is equivalent to some serial schedule Concurrency control enforces serializability 2PL - Deadlock -Granularity Other strategies Optimistic To improve performance

New forms of Consistency Range of applications can tolerate stale data –Shopping carts, etc. This is not the ACID kind of consistency Consistency involves: –How/when processes see updates to stored objects –Assume multiple copies of data –Storage system – large, distributed, guarantee durability and availability

Consistency Strong consistency – If a committed process updates data, subsequent accesses by a process will return updated value Weak consistency – no guarantee subsequent accesses return updated value –Inconsistency window – period between update and when guarateed will see update

Eventual consistency Eventual consistency – form of weak –If no new updates, eventually all accesses return last updated value Size of inconsistency window determined by communication delays, system load, number of replicas Implemented by domain name system (DNS)

MongoDB – ensure atomic updates Guarantee ACID properties for individual write or insert operations –If want to update 6 rows and only 2 rows are updated, the other 4 are never updated –Running MongoDB with Fractal Tree Indexes is fully transactional 39