1

Transactions

Chapter 21.1-21.3

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

• Atomicity

• Consistency

• Isolation

• Durability

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);

1818

    Another locks example

T1write-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);

T2write-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

2121

    Same Lock example

T1write-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);

T2write-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

2222

    Another Lock Example 

T1

read-item (E);

write-item(S)

T2

read-item (S);

write-item (E);

2323

     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

2626

     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 strategiesOptimistic

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