Type LocK based in Concurrency Control.pptx

Lock based Control

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.