Part 1: Concurrent Transactions and need for Locks

Concurrent transactions are faster.

Things to worry about (concurrency control)

Lost Update - when two transactions try access the same data at the same time

Uncommitted Dependency - if a transaction makes bad data, and a second uses that data and creates changes

Inconsistent Analysis - A function reads data that has changed and some data that hasnt changed yet

Lost update & Locks

A lock - locks abit of data so that this wont happen

Lock Manager - keeps record of all the locks

eXclusive locks (xlock) - only one transaction can use it

Shared lock (slock) - multiple transactions can use it, only read it tho

Uncommitted Dependency Example

Needs to be atomic - either committed or rolled-back

FIX extend lock till after commit or roll-back

Inconsistent Analysis

Problem: Value of ACC3 changed during lifetime of TA

Shared locks fix this (read only lock)

Part 2: Serialisability

Is the condition that we can garantee that transactions will not interfere with one another

Growing phase = making locks or convert S to X

Shrinking phase = releasing locks or convert X to S

2-phase locking protocol (2PL)

1. Before operating on data, transaction must acquire a lock

2. After releasing a lock, the transaction must NOT acquire anymore locks, i.e. all locks must be got at the start

Must use locks

Locks Must be held for the entire transaction

Part 3: Deadlocks

When two transactions are waiting for one another

Solution: create a ‘wait for graph’, stores who is waiting for who

Detect if two transactions are depenet on one another

OR look if how long a transaction has held a lock

Then rollback one of the transactions

Extra TIMESTAMP lock alternative

It is way less efficient than using a lock