← Back to Questions
SQL

What is pessimistic locking?

Learn What is pessimistic locking? with simple explanations, real-time examples, interview tips and practical use cases.

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


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.

Why this SQL question is important?

This interview question helps candidates understand real-time backend development concepts, practical problem solving, coding fundamentals, system design basics and production-ready application behavior.

Practice this question carefully for Java backend roles, Spring Boot developer interviews, microservices interviews, company interviews and full-stack developer preparation.

About the Author

Naresh Kumar is a Senior Java Backend Engineer with experience building enterprise applications using Java, Spring Boot, Microservices, Docker, Kubernetes and Cloud technologies.