Scribd
Upload
5 views

Unit IV - Concurrency Control Using Locks in Distributed Systems

The document discusses concurrency control in distributed systems, focusing on the lost update problem where simultaneous transactions can overwrite each other's changes, leading to data inconsistencies. It explains lock-based concurrency control methods, including pessimistic and optimistic locks, and outlines challenges such as deadlocks, lock granularity, and scalability. Additionally, it covers deadlock detection and recovery strategies, emphasizing the importance of balancing performance and recovery in distributed environments.

Uploaded by

studybunkers
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
5 views

Unit IV - Concurrency Control Using Locks in Distributed Systems

The document discusses concurrency control in distributed systems, focusing on the lost update problem where simultaneous transactions can overwrite each other's changes, leading to data inconsistencies. It explains lock-based concurrency control methods, including pessimistic and optimistic locks, and outlines challenges such as deadlocks, lock granularity, and scalability. Additionally, it covers deadlock detection and recovery strategies, emphasizing the importance of balancing performance and recovery in distributed environments.

Uploaded by

studybunkers
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

Concurrency Control Using

Locks in Distributed Systems


Lost Update Problem
A lost update problem occurs when two transactions update the same record in a
database management system (DBMS) at the same time, and the second
transaction overwrites the first
Lost Update Problem Example
Imagine an online banking system where multiple users can perform transactions on the same account simultaneously. For example:

● Initial Balance: $1000

● Scenario:
○ User A initiates a withdrawal of $100.
○ User B simultaneously initiates a deposit of $100.

Step-by-Step Breakdown:

1. User A's Transaction:


○ The system checks the account balance: $1000.
○ Since $1000 is sufficient, the system prepares to deduct $100.

2. User B's Transaction (While User A's is in progress):


○ User B also checks the account balance: $1000.
○ The system prepares to add $100 to the balance.

3. Order of Operations:
○ User A updates the balance to $900 ($1000 - $100).
○ Before this update is finalized, User B sets the balance to $1100 ($1000 + $100), overwriting User A’s update.

Final Outcome:
The account balance is incorrectly set to $1100 instead of the expected $1000.

Why Does This Happen?


This issue, called the lost update problem, arises because multiple transactions operate on the same data without proper synchronization. Each transaction
independently reads and modifies the balance, overwriting the other's changes.
Lost Update Problem Example
Lost Update Problem Example 2
Concurrency Control
In distributed systems, multiple clients, processes, or transactions often need to
access and modify shared resources or data simultaneously.
Concurrency control is essential to ensure that these concurrent operations do not
lead to conflicts, data inconsistencies, or unexpected behavior, ultimately
preserving data integrity and system reliability.
Concurrency control with locks
In distributed systems, concurrency control with locks is a popular technique to
manage access to shared resources, ensuring data consistency and integrity
across multiple nodes or processes.
Lock-based concurrency control relies on locking mechanisms that allow only one
process to access a resource at a time, which can prevent conflicts and maintain a
sequential execution order for operations.
Types of Locks in Distributed Systems
Pessimistic Locks

● Definition: Assumes conflicts are likely and locks resources from the beginning until a transaction completes.
● Types:
○ Exclusive Lock (Write Lock): Only one transaction can write to the resource, and no other transactions can read or
write until the lock is released.
○ Shared Lock (Read Lock): Multiple transactions can hold a shared lock for reading, but no transaction can write until
all shared locks are released.
● Usage: Suitable for high-contention environments, where it’s essential to prevent conflicts actively.

Optimistic Locks

● Definition: Assumes conflicts are rare and does not restrict access upfront. Conflicts are checked at commit time.
● Implementation: Rather than using physical locks, a version number or timestamp is often used. If data has changed since
the read, the transaction is aborted.
● Usage: Preferred in low-contention systems where most operations do not conflict.
Pessimistic Locking
Optimistic Locking
Challenges and Considerations with Lock-Based
Concurrency Control
1. Deadlocks
○ Description: Occurs when two or more transactions are waiting indefinitely for each other to release locks.
○ Mitigation Techniques:
■ Deadlock Detection: Monitor the system for circular wait patterns and resolve deadlocks by rolling back one of
the transactions.
■ Deadlock Prevention: Use techniques such as setting a lock timeout or enforcing an ordering of resource
access to avoid circular waits.
2. Lock Granularity
○ Description: Defines the size of the data locked (e.g., entire database, table, row, or field).
○ Trade-offs:
■ Coarse-Grained Locks: (e.g., table-level locks) are easier to manage but reduce concurrency.
■ Fine-Grained Locks: (e.g., row-level locks) increase concurrency but add overhead and complexity.
3. Scalability and Performance
○ Centralized locking mechanisms may struggle under high demand, while distributed approaches increase complexity
and may suffer from latency due to consensus protocols.
○ Solution: Choose a locking granularity and approach based on workload characteristics. For instance, use fine-grained
distributed locks for high-concurrency applications like distributed databases.
Distributed Deadlocks
and Transaction Recovery
Distributed Deadlocks
Definition: A distributed deadlock occurs when two or more transactions in
a distributed system form a circular wait on resources, preventing progress.

Example:

● Transaction T1 locks Resource R2 and waits for Resource R1.


● Transaction T2 locks Resource R1 and waits for Resource R2.
● Neither transaction can proceed, causing a deadlock.
Deadlock Detection Technique
Wait-For Graph (WFG)

● Each node represents a transaction.


● An edge from T1 to T2 means T1 is waiting for a resource held by T2.
● Cycle in the graph = Deadlock.
Wait for Graph - Deadlock Detection Processing Types
1. Centralized Detection
○ A central coordinator builds the WFG for all nodes.
○ Simple but introduces a single point of failure.

2. Distributed Detection
○ Each node monitors its WFG and communicates with others to identify
cycles.
○ Scalable but more complex and prone to communication overhead.
Deadlock Recovery Strategies
1. Transaction Abortion
○ Abort one or more transactions in the deadlock cycle to release resources.
○ Criteria for selection:
■ Transaction priority.
■ Rollback cost.
■ Number of resources held.

2. Timeout-Based Recovery
○ Abort transactions that exceed a predefined wait time.
○ Pros: Easy to implement.
○ Cons: May abort non-deadlocked transactions unnecessarily.

3. Prevention-Based Recovery
○ Ensure no circular waits occur by:
■ Enforcing a resource acquisition order.
■ Limiting resource holding time.
Challenges in Distributed Deadlock Recovery
Latency: Communication delays can make cycle detection slow.

False Positives: Incorrectly detecting deadlocks due to delayed updates in WFG.

Transaction Dependencies: Rolling back one transaction can impact others, leading to cascading aborts.

Resource Contention: Resource wastage. Frequent deadlocks in high-contention environments require fine-tuned recovery policies.
Key Takeaways from Deadlock Detection & Recovery
● Detection vs. Prevention:
○ Detection: Identify deadlocks when they occur and resolve them.
○ Prevention: Avoid conditions leading to deadlocks.

● Choose Strategy Based on System Requirements:


○ Centralized Systems: Centralized detection works well.
○ Large-Scale Systems: Distributed detection is necessary.

● Balancing Recovery and Performance: Avoid frequent transaction rollbacks to ensure system efficiency.

You might also like