Concurrency control refers to rules that determine how multiple users can access a shared resource simultaneously without interfering with each other. Lock-based protocols are commonly used to implement concurrency control in databases by controlling read and write access through shared and exclusive locks. Two-phase locking protocol establishes that transactions must acquire all locks in a growing phase before releasing any locks in a shrinking phase to help ensure consistency. Timestamp-based concurrency control assigns timestamps to transactions and uses their order to determine precedence if conflicts occur.

1. Concurrency Control

2. 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.

3. 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.

4. 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.

5. Real-World Examples
• Ticket Booking Systems: When you book a movie or a flight ticket
online, the system uses locks. While you're selecting your seat, a
shared lock is probably placed on it, preventing others from grabbing
it at the same time. Once you move to the payment stage, that likely
changes into an exclusive lock to make sure no one else can book the
same seat while you're completing the transaction.
• ATM Transactions: At an ATM, when you're withdrawing money, an
exclusive lock is placed on your account. This prevents any other
transaction (either another ATM withdrawal or an online transfer)
from messing with your balance while you're in the middle of the
process.

6. 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).

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

8. • 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.

9. 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.

10. 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.

11. 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.

12. Time stamp based Control
• At the heart of timestamp-based concurrency control is the idea of
assigning a unique timestamp to each transaction when it enters the
database system. Think of it like a label with the exact time of arrival.
These timestamps determine the order in which transactions should
be processed to keep the database consistent.

13. 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.

14. Real-World Example: Online Ticket Sales
Imagine you're trying to buy concert tickets online, along with
thousands of other fans.
• Timestamps: Every ticket purchase attempt receives a timestamp at
the exact moment the transaction begins.
• Seat Conflict: You and another fan try to purchase the same seat at
virtually the same time. Your transaction might have a timestamp a
fraction of a second earlier than the other person's.
• The Resolution: Because your transaction is 'older,' it will succeed.
The other fan's transaction, even though it might have been a tiny bit
later, might be either rolled back (forcing them to restart their
purchase attempt) or simply ignored (with a message saying the seat
was no longer available).

15. Benefits of Timestamp-Based Control
• Prevents Deadlocks: The strict ordering by timestamps eliminates the
type of circular waits that lead to deadlocks.
• No Waiting: Transactions don't get stuck waiting for locks to be
released