Reference: https://en.wikipedia.org/wiki/Isolation_(database_systems)

Isolation is typically defined at database level as a property that defines how or when the changes made by one operation become visible to others.

Read phenomena

Dirty reads

A dirty read (aka uncommitted dependency) occurs when a transaction is allowed to read data from a row that has been modified by another running transaction and not yet committed.

Non-repetable reads

A non-repeatable read occurs when, during the course of a transaction, a row is retrieved twice and the values within the row differ between reads.

Phantom reads

A phantom read occurs when, in the course of a transaction, new rows are added or removed by another transaction to the records being read.

Isolation levels

Of the four ACID properties in a DBMS (Database Management System), the isolation property is the one most often relaxed.

For many database applications, the majority of database transactions can be constructed to avoid requiring high isolation levels (e.g. SERIALIZABLE level), thus reducing the locking overhead for the system.

Serializable

The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable.

When using non-lock based concurrency control… And also range-locks must be acquired when a SELECT query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon.

Snapshot isolation

snapshot isolation is a guarantee that all reads made in a transaction will see a consistent snapshot of the database (in practice it reads the last committed values that existed at the time it started), and the transaction itself will successfully commit only if no updates it has made conflict with any concurrent updates made since that snapshot.

Repeatable reads

Range-locks are not managed, so phantom reads can occur.

Read committed

Read locks are released as soon as the SELECT operation is performed, so the non-repeatable reads phenomenon can occur in this isolation level.

Read uncommitted

No read locks. Dirty reads are allowed, so one transaction may see not-yet-committed changes made by other transactions.