Optimistic locking assumption: does it assume conflicts will occur frequently?

Introduction / Context:
Two broad concurrency strategies exist: pessimistic locking (assume conflicts, lock early) and optimistic concurrency control (assume conflicts are rare, validate at commit). This question probes whether you know the core assumption behind optimistic locking.

Given Data / Assumptions:

• Optimistic control uses version numbers, timestamps, or hashes to detect concurrent updates at commit time.
• Pessimistic locking places locks ahead of time to prevent conflicts.
• High-read, low-write workloads benefit from optimistic approaches.

Concept / Approach:
Optimistic locking assumes conflicts are unlikely; therefore, it avoids blocking locks during the transaction. At commit, it verifies that the record was not modified by another transaction since it was read. If changed, the update fails and must be retried.

Step-by-Step Solution:
Evaluate the statement: it claims optimistic locking assumes conflicts will occur.This actually describes pessimistic locking rationale.Thus, the statement is false.

Verification / Alternative check:
Check common implementations (ROWVERSION in SQL Server, xmin in PostgreSQL, ORMs with @Version): they perform a check at UPDATE/DELETE to detect rather than preempt conflicts.

Why Other Options Are Wrong:
Isolation level does not change the basic assumption; optimistic control is not limited to distributed systems.

Common Pitfalls:
Using optimistic control on hot rows with frequent writes can cause many retries; conversely, using pessimistic locking everywhere can cause contention and deadlocks.

Final Answer:
Invalid statement