Существует различие между Atomicity и READ COMMITTED, если реализация последнего основана на блокировке.
Рассмотрим транзакции A и B. Транзакция A представляет собой один SELECT для всех записей со статусом «ожидание» (возможно, полное сканирование очень большой таблицы, поэтому это занимает несколько минут).
At 3:01 transaction A reads record R1 in the database and sees its status is 'New' so doesn't return it or lock it.
At 3:02 transaction B updates record R1 from 'New' to 'Pending' and record R2000 from 'New' to 'Pending' (single statement)
At 3:03 transaction B commits
At 3:04 transaction A reads record R2000, sees it is 'Pending' and committed and returns it (and locks it).
В этой ситуации выбор в транзакции A видел только часть транзакции B, нарушающую атомарность. Технически, хотя, выборка только возвратила подтвержденные записи.
Базы данных, полагающиеся на блокировку чтения, страдают от этой проблемы, потому что единственным решением было бы заблокировать всю читаемую таблицу, чтобы никто не мог обновить какие-либо записи в любой из них. Это сделало бы непрактичным любое параллельное действие.
На практике большинство приложений OLTP имеют очень быстрые транзакции, работающие на очень маленьких объемах данных (по сравнению с размером базы данных), и параллельные операции имеют тенденцию попадать в разные «кусочки» данных, поэтому ситуация возникает очень редко. Даже если это произойдет, это не обязательно приведет к заметной проблеме, и даже если это так, их очень трудно воспроизвести, и для их исправления потребуется совершенно новая архитектура. Короче говоря, несмотря на то, что это теоретическая проблема, на практике о ней часто не стоит беспокоиться.
При этом архитектор должен знать о потенциальной проблеме, уметь оценивать риск для конкретного приложения и определять альтернативы.
Это одна из причин, по которой SQL Server добавил неблокирующие согласованные операции чтения в 2005 .