IF Notes

Snapshot Isolation

3 min read

Back to IF3140 Sistem Basis Data

5.1: Snapshot Isolation (SI)

Questions/Cues

  • Apa motivasi Snapshot Isolation?

  • Apa ide dasar SI?

  • Bagaimana aturan Read SI?

  • Bagaimana aturan Write SI?

  • Bagaimana aturan Commit SI?

  • Apa itu First-Committer Wins?

  • Apakah SI menjamin serializability?

  • Apa anomali di SI?

  • Apa itu Write Skew?

  • Apa level isolasi SI di SQL?

Reference Points

  • Slides “11 - Concurrency Control - 4.pdf” (Hal 8-15)

Motivasi: Kebutuhan Level Isolasi Baru

Serializability (dijamin oleh 2PL, MVCC, dll) adalah jaminan terkuat, tetapi seringkali terlalu ketat dan “mahal” (lambat) untuk banyak aplikasi.

Snapshot Isolation (SI) muncul sebagai level isolasi yang populer:

  • Lebih lemah dari serializability (membolehkan beberapa anomali).

  • Lebih kuat dari Read Committed (level default di banyak DB).

  • Memberikan performa tinggi (terutama untuk read).

Ide Dasar Snapshot Isolation

Setiap transaksi Ti seolah-olah “mengambil foto” (snapshot) dari basis data pada saat ia dimulai (Start(Ti)).

Aturan Eksekusi SI

  1. Aturan Read:

    • Saat Ti read(Q), ia akan membaca versi Q yang ada di dalam snapshot-nya.

    • Yaitu, versi Q terbaru yang sudah di-commit pada saat Start(Ti).

    • Operasi read tidak pernah di-block.

  2. Aturan Write:

    • Saat Ti write(Q), ia menulis ke versi privat miliknya (tidak terlihat transaksi lain).

  3. Aturan Commit (Validasi):

    • Saat Ti ingin commit, ia harus lolos tes validasi yang disebut First-Committer Wins.

Validasi: First-Committer Wins

Validasi Ti akan GAGAL (dan Ti di-rollback) jika ada transaksi lain (Tj) yang memenuhi SEMUA kondisi berikut:

  1. Tj berjalan konkuren dengan Ti (waktu hidup mereka overlap).

  2. Tj sudah commit lebih dulu daripada Ti.

  3. Tj menulis (WS(Tj)) setidaknya satu item data yang juga ditulis oleh Ti (WS(Ti)).

Dengan kata lain: Jika ada “konflik tulis-tulis” (Write-Write Conflict) yang tumpang tindih, siapa yang commit pertama, dia yang menang. Yang commit belakangan akan rollback.

Anomali: SI Tidak Serializable

Snapshot Isolation TIDAK menjamin serializability. Anomali utamanya adalah Write Skew.

Contoh Write Skew (Slide 12):

  • Batasan: A + B tidak boleh negatif. Awal: A=100, B=100.

    1. T1 (Start): Ambil snapshot (A=100, B=100).

    2. T2 (Start): Ambil snapshot (A=100, B=100).

    3. T1: read(A) (A=100).

    4. T2: read(B) (B=100).

    5. T1: Cek (100 + B) >= 150? (T1 anggap B=100, jadi 200 >= 150 → OK).

    6. T1: write(A = A - 150) (A = -50 di versi privat T1).

    7. T2: Cek (A + 100) >= 150? (T2 anggap A=100, jadi 200 >= 150 → OK).

    8. T2: write(B = B - 150) (B = -50 di versi privat T2).

    9. T1 (Commit): Validasi sukses (T1 dan T2 tidak ada write-write conflict, karena T1 tulis A, T2 tulis B). Commit A = -50.

    10. T2 (Commit): Validasi sukses. Commit B = -50.

Hasil Akhir: A = -50, B = -50. Total A + B = -100. Batasan dilanggar! Ini bukan serializable.

Summary

Snapshot Isolation (SI) adalah level isolasi populer di mana transaksi membaca dari “foto” (snapshot) database pada saat ia dimulai (Start(Ti)), sehingga read tidak pernah block. Saat commit, ia menggunakan validasi First-Committer Wins, yang akan me-rollback transaksi jika ada write-write conflict (tumpang tindih penulisan) dengan transaksi lain yang commit lebih dulu. SI tidak serializable dan rentan terhadap anomali Write Skew, di mana dua transaksi konkuren membuat keputusan berdasarkan data usang yang mereka baca, yang menyebabkan inkonsistensi.

Graph View

Backlinks