ISC2 Certified Secure Software Lifecycle Professional (CSSLP) Practice Question

During testing, two concurrent transactions sometimes overwrite each other's changes to the same customer record, causing lost updates. The development team wants to allow many users to read data simultaneously but detect and reject conflicting writes only when a transaction is committed. Which database concurrency control should they implement to best address this requirement?

Lower the isolation level to READ UNCOMMITTED to increase throughput and avoid locks.
Implement optimistic locking that compares a version or timestamp column at commit time.
Disable automatic commit so transactions stay open until the application explicitly ends them.
Use pessimistic locking so each transaction obtains an exclusive lock when the row is first read.

Report Issue

Answer Description

Lost-update problems occur when multiple transactions read the same data, make changes, and then save, overwriting one another. Optimistic locking addresses this by letting transactions read without locking; just before commit, the database checks a version, timestamp, or checksum to see whether another transaction has modified the row. If a conflict is detected, one transaction is rolled back, preserving data integrity.

Pessimistic locking (such as SELECT … FOR UPDATE) prevents concurrent reads or writes by acquiring locks early, which reduces concurrency. Read-uncommitted isolation intentionally allows dirty reads and would not prevent lost updates. Disabling auto-commit changes transaction boundaries but provides no conflict detection mechanism. Therefore, optimistic locking is the most appropriate choice.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.