Locking

Question 1

Locking

Answer 1

Used to enforce conflict serialisability.

Question 2

Simple Lock Mechanism

Answer 2

Used to ensure that a transaction has to lock an item before it can access it, which are requested and granted by the scheduler.
Each item is locked at most one transaction at a time, and transactions wait until a lock can be granted.
These locks have to be released eventually.
This is SIMILAR in theory to what serialization does in terms of setting the isolation of the transaction.

Question 3

Lock Denoted

Answer 3

Locking -> l_i(x)
Unlocking -> u_i(x)

Question 4

Example of locking

Answer 4

l_1(x) would request the lock for transaction one for the item x.
u_1(x) would release this lock.
If there was a l_2(x) between these two, then transaction two will have to wait for transaction one to finish what it is doing.

Question 5

Two Phase Locking

Answer 5

All lock operations in each transaction precede all unlocks.
Phase 1 is requesting locks, and phase 2 is unlocking.
So in other words, there cannot be an unlock which happens before a lock, even if they lock/unlock different things.

Question 6

Deadlocks

Answer 6

Transactions may be forced to wait forever.
If we take the example above, if transaction 2 starts before transaction 1 can get to locking y, then neither can proceed forward since we are waiting for either of them to release their locks.

Question 7

Deadlock Solution

Answer 7

Using more flexible locks.

Question 8

Shared Locks (read-locks)

Answer 8

Requested by transactions to read an item x.
Granted to several transactions at the same time.
Operation : s-lock(x)
Shared lock on x is granted only if no other transactions hold the exclusive lock for x.

Question 9

Exclusive Locks (write-locks)

Answer 9

Requested by transactions to write an item x.
Granted to at most one transaction at a time.
Operation : x-lock(x)
Shared lock on x is granted only if no other transactions hold ANY lock for x.

Question 10

Upgrading Locks

Answer 10

A shared lock on item x can be upgraded later to an exclusive lock on x i order to be friendly to other transactions.

Question 11

Deadlock Solution (Shared and exclusive locks)

Answer 11

Using shared and exclusive locks can still lead to deadlock. For example:
sl_1(x), r_1(x), sl_2(x), r_2(x)
If both transactions have xl_i(x) after them, then since it requires X having no locks, we are stuck in deadlock.

Question 12

Update Lock

Answer 12

Requested by transactions to read (not write) an item, and may be upgraded to exclusive locks.
Granted to at most on transaction at a time.
Operation : u-lock(x)

Question 13

Upgrade System

Answer 13

If you have a shared lock, you can upgrade to update lock, but not vice versa (you cannot upgrade from update to shared lock).
We cannot use exclusive locks at all from either shared locks or upgrade locks.
You can go from shared lock to shared lock, but not update lock to update lock.

Question 14

Locking too broadly

Answer 14

Low overhead (less locks to be stored, aka less information), but less degree of concurrency (since less locks may cause more concurrent schedules, and may cause delays).

Question 15

Locking too finely

Answer 15

High overhead since we have more locks, but high degree of concurrent with no delays.

Question 16

Intention Locks

Answer 16

IS requests a shared lock on a sub-item whilst IX requests an exclusive lock on a sub-item.