Apa itu tingkat isolasi transaksi?

Question

Accepted Answer

**Isolation levels** mengontrol seberapa banyak transaksi konkuren dapat melihat perubahan uncommitted (atau in-progress) satu sama lain — melakukan trade-off antara **consistency** dan **performance/concurrency**. Isolasi yang lebih tinggi mencegah lebih banyak anomali tetapi meningkatkan locking/contention.

## Anomali concurrency (apa yang isolasi cegah)

```text
DIRTY READ        → reading another transaction's UNCOMMITTED changes (which may roll back)
NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it)
PHANTOM READ      → re-running a query returns different ROWS (another txn INSERTED/DELETED)
```

Ini adalah masalah yang dapat terjadi ketika transaksi berjalan secara konkuren — isolation levels mengontrol mana yang dicegah.

## Empat tingkat isolasi standar

Setiap level yang lebih tinggi mencegah lebih banyak anomali. **Read Committed** adalah default umum (mencegah dirty reads); **Serializable** adalah yang paling ketat (transaksi berperilaku seolah-olah berjalan satu per satu) tetapi paling membatasi untuk concurrency.

## Mengatur isolation level

```sql
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- ... operations run at the chosen isolation ...
COMMIT;
```

## Trade-off fundamental

```text
Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention
                   → lower concurrency, potential slowdowns, more deadlocks
Lower isolation  → MORE concurrency/performance, but risk of anomalies
→ Choose based on the data's needs: financial/critical data may need Serializable;
  most apps use Read Committed (the default) as a balance.
→ Note: implementations vary (MVCC vs locking); the SQL standard defines the levels
  but databases differ in details (Postgres, MySQL/InnoDB, etc.).
```

## Mengapa ini penting

Tingkat isolasi transaksi adalah pengetahuan advanced yang penting untuk memahami **concurrency dalam database** — ketika multiple transaksi berjalan simultaneously (seperti yang terjadi di aplikasi multi-user real apa pun), isolation levels menentukan trade-off antara data consistency dan performance, jadi memahaminya berharga untuk membangun concurrent applications yang correct dan performant.

Konsep inti adalah **concurrency anomalies** (dirty reads, non-repeatable reads, phantom reads — masalah yang muncul ketika transaksi melihat in-progress changes satu sama lain) dan bagaimana **empat isolation levels** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) secara progresif mencegah lebih banyak dari anomali tersebut.

Memahami ini penting untuk correctness: memilih isolation level yang terlalu rendah dapat memungkinkan anomali yang merusak data atau menghasilkan hasil yang salah (misalnya membaca data uncommitted yang kemudian rollback, atau inconsistent reads), sementara memilih yang terlalu tinggi mengurangi concurrency dan performance.

**Trade-off fundamental** — higher isolation berarti lebih banyak correctness tetapi lebih banyak locking/contention (lower concurrency, potential slowdowns dan deadlocks), lower isolation berarti lebih banyak performance tetapi risk of anomalies — adalah insight kunci: Anda memilih level berdasarkan consistency requirements data (data critical/financial mungkin memerlukan Serializable; sebagian besar aplikasi menggunakan Read Committed sebagai balance).

Mengetahui bahwa implementasi bervariasi (MVCC vs locking) juga relevan.

Karena concurrency adalah inherent dalam real database applications, dan karena isolation levels mengatur critical balance antara consistency dan performance (dengan pilihan yang salah menyebabkan either data anomalies atau performance problems), memahami isolation levels — anomalies, levels, dan consistency-vs-concurrency trade-off — adalah valuable senior-level knowledge untuk membangun correct, performant concurrent systems dan common advanced interview topic yang menunjukkan understanding database concurrency.