How is atomic rule ensured when using default (read commited) isolation mode?

Question

An important property of transaction is atomicity.

The default mode is read commited. This prevents dirty reads. But we have problem of repeatable reads and phantom rows.

How is atomic rule ensured when using default (read commited) isolation mode?

Example- in tran1 I read value from table1. While tran1 is still running, I start tran2 and update the same value in table1. So tran1 has got stale value.

Answer 1

Read committed isolation mode does not prevent updates of the rows you have read in your transaction while your transaction is still open.

If you want to prevent this, then you'll need to set the isolation level to REPEATABLE READ (or SERIALIZABLE). Or you can set the READ_COMMITTED_SNAPSHOT option of your database to ON.

Answer 2

According to this article, 'read committed' does not guarantee 'atomicity`:

Unfortunately, that assumption is not correct when using read committed. The read committed isolation level guarantees that only committed data will be read; it does NOT guarantee how much of the committed data will be returned and is prone to inconsistent analysis problems. If you want to avoid inconsistent analysis, you’d need to increase your isolation level (if using locking) or change to versioning for read committed (or even snapshot isolation).

The wikipedia says:

non-repeatable reads phenomenon can occur in this isolation level)

but I don't think wikipedia means it breaks 'atomicity'.