Lock-based protocols in DBMS Theory - Step-by-Step Execution

Concept Flow - Lock-based protocols

Transaction requests lock

↓

Is lock available?

No→Wait until lock is free

Yes↓

Lock granted

↓

Transaction performs operations

↓

Transaction releases lock

↓

Other waiting transactions notified

↓

Transaction requests lock

This flow shows how transactions request locks, wait if needed, perform operations, and release locks to ensure safe data access.

Execution Sample

DBMS Theory

Transaction T1 requests lock on DataItem A
Lock is free, T1 granted lock
T1 reads and writes DataItem A
T1 releases lock on DataItem A
Transaction T2 requests lock on DataItem A
Lock is free, T2 granted lock

This example traces two transactions requesting and releasing locks on the same data item sequentially.

Analysis Table

Step	Transaction	Action	Lock Status on DataItem A	Result
1	T1	Requests lock	Free	Lock granted to T1
2	T1	Reads/Writes DataItem A	Locked by T1	Operation successful
3	T1	Releases lock	Locked by T1	Lock released, now free
4	T2	Requests lock	Free	Lock granted to T2
5	T2	Reads/Writes DataItem A	Locked by T2	Operation successful

💡 No more transactions requesting lock; process ends

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
Lock Status on DataItem A	Free	Locked by T1	Locked by T1	Free	Locked by T2	Locked by T2

Key Insights - 2 Insights

Why does Transaction T2 have to wait if T1 holds the lock?

Because the lock is exclusive, only one transaction can access the data item at a time. As shown in step 1 and 4, T2 can only get the lock after T1 releases it in step 3.

What happens if a transaction tries to access data without a lock?

It risks reading or writing inconsistent data. Lock-based protocols prevent this by granting locks before access, as seen in the execution table where operations happen only after lock is granted.

Visual Quiz - 3 Questions

Look at the execution table, what is the lock status on DataItem A after step 3?

A Locked by T1

B Free

C Locked by T2

D Waiting

💡 Hint

Check the 'Lock Status on DataItem A' column at step 3 in the execution_table

At which step does Transaction T2 get the lock on DataItem A?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for when T2 requests and is granted the lock in the execution_table

If Transaction T1 did not release the lock at step 3, what would happen to Transaction T2's request?

A T2 would get the lock immediately

B T2 would abort its operation

C T2 would wait until the lock is released

D T2 would share the lock with T1

💡 Hint

Refer to the concept_flow where transactions wait if the lock is not free

Concept Snapshot

Lock-based protocols control access to data by granting locks to transactions.
Only one transaction can hold an exclusive lock on a data item at a time.
Transactions must wait if the lock is held by another.
Locks are released after operations to allow others access.
This ensures data consistency and prevents conflicts.

Full Transcript

Lock-based protocols manage how multiple transactions access the same data safely. When a transaction wants to use a data item, it requests a lock. If the lock is free, it is granted immediately. If not, the transaction waits. After finishing its operations, the transaction releases the lock, allowing others to proceed. This process prevents conflicts and keeps data consistent. The execution table shows two transactions, T1 and T2, accessing the same data item sequentially by acquiring and releasing locks. Key points include waiting for locks and exclusive access. Understanding this flow helps ensure safe database operations.