During testing, a report transaction reads account balances that another transaction has changed but not yet committed. The other transaction then rolls back, so the report has shown values that never officially existed. Which ACID property is not being adequately enforced?
Select an answer to reveal the explanation.
Short Explanation
Isolation means each transaction gets to work as if it were alone in the room. Reading someone else's half-finished, uncommitted changes is a dirty read, and that's an isolation problem. The writer did roll back correctly, so you can't blame atomicity.
Full Explanation
Isolation determines how far concurrent transactions are shielded from each other's in-progress work. Reading uncommitted changes, a dirty read, is allowed only at the lowest isolation level, read uncommitted; at read committed and above, the reader sees only committed data, either by waiting on locks or by reading a committed version through row versioning. Because the report saw values that were later rolled back, isolation was too weak for its purpose, and raising the session's isolation level or removing a no-lock hint would prevent it. Atomicity was actually honored: the writing transaction rolled back completely, undoing all its changes; the problem is that another transaction observed them before the rollback. Durability concerns whether committed changes survive failures; here the issue involves uncommitted data, so durability does not apply. Consistency ensures a transaction preserves defined rules and constraints; the writer's intermediate values may have been perfectly valid, but they were visible too early, which is a concurrency control failure. Exam caveat: higher isolation levels prevent more anomalies, including non-repeatable reads and phantoms, at the cost of more blocking or versioning overhead. Operational check: review the report's connection settings and query hints, set at least read committed and repeat the concurrent test.