Pessimistic locking is a concurrency control mechanism in databases where data is locked immediately when a transaction accesses it, preventing other transactions from modifying the same data until the lock is released.
In simple words:
Pessimistic locking assumes conflicts are likely, so it locks data early to prevent concurrent modification problems.
Why Pessimistic Locking is Important
Enterprise systems often handle:
- Critical financial transactions
- High-contention updates
- Inventory processing
- Real-time concurrent operations
Without proper locking:
- Data corruption may occur
- Concurrent updates may conflict
- Critical transactions may fail
Pessimistic Locking Solves These Problems
By:
- Blocking concurrent access during transactions
Simple Real-Life Example
Think about:
- A cinema ticket booking system
Scenario
- User A selects Seat A1
Problem
If User B also selects:
- Seat A1 simultaneously
Pessimistic Locking Solution
As soon as User A selects Seat A1:
- Seat becomes locked
Result
- User B must wait
- Double booking prevented
Pessimistic Locking Works Similarly
Database locks records:
- Before modification begins
Pessimistic Locking Internal Architecture
Transaction Starts
|
v
Acquire Lock
|
v
Other Transactions Blocked
|
v
Modify Data
|
v
Commit/Rollback
|
v
Release Lock
Main Purpose of Pessimistic Locking
- Prevent conflicting updates
- Maintain strict consistency
- Avoid lost updates
- Protect critical transactions
How Pessimistic Locking Works
When transaction accesses data:
- Database immediately locks rows/tables
Until Transaction Completes
- Other conflicting transactions wait
Example Table
| account_id | balance |
|---|---|
| 1 | 1000 |
Transaction Example
START TRANSACTION; SELECT * FROM accounts WHERE account_id = 1 FOR UPDATE;
What Happens?
- Row becomes locked
- Other updates must wait
Update Operation
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
Commit Transaction
COMMIT;
After COMMIT
- Lock released
Pessimistic Locking Query Flow
Start Transaction
|
v
Acquire Lock
|
v
Other Transactions Wait
|
v
Modify Data
|
v
Commit/Rollback
|
v
Release Lock
What Problem Does Pessimistic Locking Prevent?
Pessimistic locking mainly prevents:
- Lost updates
- Dirty writes
- Concurrent modification conflicts
Lost Update Example
Initial Balance:
1000
User A Withdraws
-500
User B Withdraws Simultaneously
-700
Without Pessimistic Locking
- Incorrect balance possible
With Pessimistic Locking
- User B waits until User A finishes
Pessimistic Locking vs Optimistic Locking
| Feature | Pessimistic Locking | Optimistic Locking |
|---|---|---|
| Assumption | Conflicts are common | Conflicts are rare |
| Locking Style | Locks data immediately | Checks conflicts later |
| Concurrency | Lower | Higher |
| Blocking | Possible | Minimal |
| Scalability | Lower | Higher |
| Conflict Handling | Prevented early | Detected during update |
When Pessimistic Locking is Best
- High-contention systems
- Critical financial operations
- Inventory management
- Frequent concurrent updates
When Optimistic Locking is Better
- Read-heavy systems
- Low conflict probability
- Highly scalable architectures
Pessimistic Locking in JPA/Hibernate
JPA supports pessimistic locking using:
- PESSIMISTIC_READ
- PESSIMISTIC_WRITE
Example
entityManager.find(
Employee.class,
1L,
LockModeType.PESSIMISTIC_WRITE
);
What Happens?
- Database row locked immediately
Main Types of Pessimistic Locks
- Pessimistic Read Lock
- Pessimistic Write Lock
1. Pessimistic Read Lock
Allows:
- Multiple readers
Blocks:
- Writers
2. Pessimistic Write Lock
Blocks:
- Other readers/writers depending on database behavior
Advantages of Pessimistic Locking
- Strong consistency
- Prevents update conflicts early
- Good for critical systems
- Reduces retry operations
Disadvantages of Pessimistic Locking
- Reduced concurrency
- Blocking issues
- Possible deadlocks
- Lower scalability
What is Deadlock?
Deadlock occurs when:
- Transactions wait for each other indefinitely
Example
Transaction A locks Row 1 Transaction B locks Row 2 A waits for Row 2 B waits for Row 1
Result
- Deadlock situation
Pessimistic Locking in Banking Systems
Banking systems heavily use pessimistic locking for:
- Fund transfers
- Balance updates
- ATM transactions
Why Important?
- Financial consistency is critical
Pessimistic Locking in E-Commerce
E-commerce systems use pessimistic locking for:
- Inventory reservation
- Ticket booking
- Flash sale systems
Example
Prevent overselling products
Pessimistic Locking in Learning Platforms
Learning systems use pessimistic locking for:
- Exam submission locking
- Assessment updates
- Concurrent grading operations
Pessimistic Locking in Microservices
Microservices architectures use pessimistic locking for:
- Distributed transaction consistency
- Inventory reservation services
- Critical payment workflows
Popular Databases Supporting Pessimistic Locking
- MySQL
- PostgreSQL
- Oracle
- SQL Server
- MariaDB
MySQL Pessimistic Lock Example
SELECT * FROM products WHERE product_id = 100 FOR UPDATE;
PostgreSQL Pessimistic Lock Example
SELECT * FROM accounts FOR UPDATE;
Oracle Pessimistic Lock Example
SELECT * FROM employees FOR UPDATE;
Best Practices
- Keep transactions short
- Avoid unnecessary locks
- Use proper indexes
- Handle deadlocks properly
- Use pessimistic locking only when necessary
Common Interview Mistake
Many developers think:
- Pessimistic locking is always better for consistency
Reality
Pessimistic locking:
- Provides strong consistency
- But may reduce scalability and concurrency
Related Learning Topics
- What is Optimistic Locking?
- What is Database Locking?
- What is Deadlock?
- What is a Transaction?
- What are ACID Properties?
Professional Interview Answer
Pessimistic locking is a concurrency control mechanism where database records are locked immediately when accessed by a transaction to prevent other transactions from modifying the same data simultaneously. It assumes conflicts are likely and prevents concurrent modification problems by blocking conflicting operations until the transaction completes. Pessimistic locking is commonly implemented using database locks such as SELECT FOR UPDATE and is widely used in critical transactional systems like banking, inventory management, ticket booking, and payment processing. Although pessimistic locking provides strong consistency and prevents lost updates effectively, it may reduce concurrency, increase blocking, and create deadlock risks in highly scalable systems. Frameworks such as JPA and Hibernate support pessimistic locking using lock modes like PESSIMISTIC_READ and PESSIMISTIC_WRITE.
Why Interviewers Like This Answer
- Clearly explains locking behavior
- Differentiates optimistic and pessimistic locking
- Includes transaction consistency concepts
- Mentions deadlocks and scalability tradeoffs
- Provides enterprise-level real-world examples
Frequently Asked Questions
What is pessimistic locking?
Pessimistic locking locks data immediately to prevent concurrent conflicts.
Why is pessimistic locking used?
It prevents conflicting updates in high-contention systems.
What is the difference between optimistic and pessimistic locking?
Optimistic locking detects conflicts later, while pessimistic locking prevents them early using locks.
What are the disadvantages of pessimistic locking?
Reduced concurrency, blocking, and possible deadlocks.
How is pessimistic locking implemented in SQL?
Using statements like SELECT ... FOR UPDATE.