ACID - Read Committed Seviyesi Nedir ?

Giriş

Şeklen şöyle. İkinci satırda Repeatable Read görülebilir.

SQL Server için şeklen şöyle

PostgreSQL için açıklama şöyle. Yani PostgreSQL'in desteklediği en düşük ve ilk seviye bu

In PostgreSQL, you can request any of the four standard transaction isolation levels, but internally only three distinct isolation levels are implemented, i.e. PostgreSQL's Read Uncommitted mode behaves like Read Committed. This is because it is the only sensible way to map the standard isolation levels to PostgreSQL's multiversion concurrency control architecture.

Designing Data Intensive Applications kitabındaki açıklama şöyle.

The most basic level of transaction isolation is read committed. It makes two guarantees:

1. When reading from the database, you will only see data that has been committed

(no dirty reads).

2. When writing to the database, you will only overwrite data that has been committed

(no dirty writes).

Yani

- Sadece Dirty Read ve Dirty Write problemini engeller. 

- Non Repeatable Read problemini engellemez. Aynı transaction içinde iki okuma farklı sonuç verebilir, çünkü başka transaction veriyi değiştirebilir.

- Lost Update problemini engellemez

- Phantom Read problemini engellemez. Benim dokunmadığım satırlar kilitlenmediği için bunlar değiştirilebilir veya yeni satır eklenebilir

- Phantom satır kapsamında Write skew problemini engellemez.

Non-Repetable Read

Örnek

Şeklen şöyle. Açıklaması şöyle

In the following diagram, the concurrent transactions see the real-time change the other made. Transaction 1 gets chris as the latest committed name even though Transaction 2 began after Transaction 1.

Burada Transaction 1 başlıyor ve 2 numaralı satırı okuyor, ancak 3 numaralı satıra dokunmuyor. Transaction 2 ise 3 numaralı satırı değiştirip commit'liyor. Transaciton 2, 3 numaralı satırı okursa değişmiş veriyi görüyor. Bu problemin ismi "Non-Repeatable Read" ve "Repeatable Read" isolation seviyesi bu problemi engeller.

Select İşlemi - Non Repeatable Read Problemi

Read Committed seviyesinde select cümlesinin başında konulan shared lock, cümle bitiminde transaction bitmemiş olsa bile kaldırılır. Açıklaması şöyle

T1 gets Read Lock, reads, and releases the Read lock asap once the read is done.

T2 can execute and update the row as it is unlocked now.

So When T1 tries to re-read the same row, it will get a different result.

Örnek

Şöyledir

T1 begins

T1 Reads A‘s Balance=Rs. 1000 [Read-1]

T2 begins

T2 Read A’s Balance= Rs. 1000 (Can read as Row= Read Locked)

(T1 reads and releases Read Lock ASAP, and the row is unlocked now)

T2 Update A’s Balance= Rs. 500 (Can Write as Write lock is free for this row)

T2 Commit. (Releases Write Lock, now row is free to Read/Write)

T1 Reads A‘s Balance=Rs. 500 [Read-2] [Different Result] [non-Repeatable]

Select İşlemi - Phantom Reads Problem

Örnek

Şöyledir

T1 begins

T1Queries select * from Tbl where X>100 → 3 rows

T2 begins

T2 Inserts 1 additional row with X=150.

T2 Commits.

T1 Queries select * from Tbl where X>100 → 4rows [Phantom Read].