Lock-based protocols are a common method for concurrency control in databases. They use shared locks and exclusive locks analogous to traffic lights. Shared locks allow multiple readers, while exclusive locks only allow one writer. This prevents incorrect data from simultaneous reads and writes. However, lock-based protocols can cause deadlocks and starvation if not properly managed. The Two-Phase Locking protocol helps address these issues by restricting when transactions can acquire and release locks.

1. Lock based Control

2. Lock – based protocol
• Lock-based protocols are a common way to implement concurrency control in
databases. Think of them as traffic lights:
• Shared Lock (Green Light): This is like the "read-only" mode. Multiple people can
view the document simultaneously. For example, several airline employees might
need to simultaneously see a flight's remaining seats to book passengers.
• Exclusive Lock (Red Light): Only one person gets to make active changes to the
document at a time. Consider a bank account balance. You wouldn't want
multiple transactions trying to withdraw or deposit money from the same
account at the exact same moment, or you'd end up with an incorrect balance.

3. Example
• What is Concurrency Control?
• Imagine you and several friends are collaborating on editing a shared document. Without any
rules, you could all end up making changes at the same time, leading to conflicts, overwrites, and
general chaos. Concurrency control is like the set of rules that determines who gets to edit the
document and when. The goal is to ensure everyone can make changes without messing up each
other's work.
• Lock-Based Protocols: The Traffic Lights of Databases
• Lock-based protocols are a common way to implement concurrency control in databases. Think of
them as traffic lights:
• Shared Lock (Green Light): This is like the "read-only" mode. Multiple people can view the
document simultaneously. For example, several airline employees might need to simultaneously
see a flight's remaining seats to book passengers.
• Exclusive Lock (Red Light): Only one person gets to make active changes to the document at a
time. Consider a bank account balance. You wouldn't want multiple transactions trying to
withdraw or deposit money from the same account at the exact same moment, or you'd end up
with an incorrect balance.

4. Important Considerations
• Deadlocks: Sometimes transactions can get stuck. Imagine
Transaction A has a lock on Data item 1 and needs Data item 2, while
Transaction B has a lock on Data item 2 and needs Data item 1.
Neither can proceed! Systems need ways to detect and resolve
deadlocks.
• Performance: Locks add overhead. Databases aim to find a balance
between allowing a lot of people to work on data simultaneously
(concurrency) and making sure the data stays accurate (consistency).

5. Pitfalls of lock-based protocols
1. Deadlocks
The classic lock-based problem. Imagine these two scenarios:
• Traffic Gridlock: Two cars arrive at a four-way intersection simultaneously. Car A wants to
turn left and needs the lane Car B currently occupies. Car B also wants to turn left and
needs the lane Car A occupies. They're both stuck, waiting for the other to move, leading
to a gridlock.
• Library Book Standoff: Two students, Alice and Bob, need two specific books for a
project. Alice picks up Book 1, and Bob picks up Book 2. They both realize they need the
other person's book to complete their work. Neither wants to put their book down first,
creating a deadlock.
Databases can face similar situations. Transactions can hold locks on different data items,
and end up in a circular waiting pattern where everyone's waiting for a resource
someone else has locked. Systems need ways to detect and break such deadlocks, often
by rolling back (undoing) one of the transactions to free up resources.

6. • Starvation
• The Forgotten Diner: A popular restaurant consistently
prioritizes large groups and walk-ins. A solo diner might keep
waiting for a table, even if smaller tables are technically
available. The diner gets "starved" of service.
• In databases, a transaction needing a large number of locks
might continuously get delayed while a stream of smaller
transactions needing fewer locks keep getting processed.
This can lead to the larger transaction perpetually waiting or
"starving" for resources.

7. What is the Two-Phase Locking Protocol (2PL)?
2PL is a concurrency control method designed to help prevent some of
the issues we discussed earlier. It establishes rules for when
transactions can acquire and release locks:
• Growing Phase: A transaction can acquire locks on data items it
needs, but it cannot release any locks yet. Imagine it's like gathering
all your tools and materials before starting a project.
• Shrinking Phase: The transaction can start releasing locks, but it can
no longer acquire new ones. This is like the cleanup phase of your
project—you can put tools away, but you shouldn't need any new
ones at this stage.

8. Example
• Growing Phase
• Framing Crew: Gets a lock on the lumber supply, preventing
others from taking wood they need.
• Plumbing Crew: Gets a lock on the plumbing pipes and fixtures.
• Electrical Crew: Gets a lock on wiring, outlets, etc.
• Shrinking Phase
• Framing Crew: Finishes their work, releases the lock on the
lumber (other crews can now use it).
• Plumbing Crew: Finishes, releases the lock on pipes.
• Electrical Crew: Finishes, releases the lock on wiring.

9. Why 2PL is Useful
• 2PL helps ensure that if multiple transactions are working on the
same data, their results can be serialized (meaning you could have
achieved the same outcome if they ran one after the other). This
helps maintain the consistency of your data.
Benefits of 2PL
• Deadlock Prevention: There can be some scenarios where 2PL helps
prevent deadlocks, since locks are released in an orderly way after
one stage is fully complete.
• Ensures Serializability: It helps guarantee order and consistency. In
our house-building example, the house could still be built in a valid
way if the crews had done their work one after the other, even if they
wouldn't have all been working at the same time.

10. Conflicts? Rollback or Ignore:
• Older Writes, Younger Reads: No problem. The younger transaction
can read the data written by the older one.
• Younger Writes, Older Tries to Read: The older transaction needs the
data as it was before the younger write. Solution: Roll back (undo) the
younger transaction and restart it, letting the older one proceed.
• Younger Writes, Older Tries to Write: The younger write has already
happened. Solution: Often, the older transaction's write is simply
ignored.