Isolation Anomaly

Masalahnya

Setiap developer aplikasi memilih isolation level database, pengaturan yang menentukan seberapa jauh dua operasi yang berjalan bersamaan boleh saling mengganggu. Hampir semua orang memakai nilai bawaan, dan hampir tidak ada yang bisa menjelaskan dari apa pengaturan itu melindungi mereka. Jenis kegagalannya diajarkan sebagai daftar nama, dirty read, non-repeatable read, phantom, yang dihafal untuk wawancara kerja tapi jarang dipahami.

Kegagalan yang paling berbahaya justru tidak ada di daftar itu. Pada write skew, dua transaksi membaca data yang sama, masing-masing mengecek aturan ("masih ada orang lain yang piket, jadi saya boleh berhenti piket"), lalu masing-masing menulis baris yang berbeda. Tidak ada yang bertabrakan, keduanya berhasil disimpan, dan aturannya dilanggar. Begitulah jadwal piket bisa kosong dan ruangan terpesan dua kali. Snapshot isolation tidak mencegahnya, padahal itulah yang sebenarnya dipakai kebanyakan pengaturan bawaan. Lebih parah lagi, nama level yang sama punya arti berbeda di tiap database. "SERIALIZABLE" di Oracle tetap membiarkan write skew.

Yang saya bangun

Database asli dijalankan lebih dulu

Developer bisa saja mengambil keputusan produksi dari apa yang ditampilkan alat ini, jadi simulatornya tidak boleh dibangun dari dugaan saya tentang database. Sebelum simulatornya ada, saya menulis harness yang menjalankan PostgreSQL, MySQL, SQL Server, dan Oracle asli di container, lalu memutar setiap jadwal di sana. Harness mencatat setiap nilai yang dibaca, setiap kode error, di mana transaksi menunggu, dan apakah transaksi itu berhasil. Ke-220 rekaman itu menjadi kunci jawaban. Kalau simulator dan rekaman berbeda, simulatornya yang salah.

Satu mesin, lima berkas aturan

Simulatornya hanya satu. Setiap database berupa berkas aturan: arti sebenarnya dari tiap nama level, kapan lock diambil, apa yang bentrok, dan kode error apa yang muncul. Perbandingan antar-database baru adil kalau mesinnya sama, dan pakar database bisa memeriksa berkas aturan tanpa membaca kode saya. Setiap aturan mengutip dokumentasi vendor, dan deploy gagal kalau ada kutipan yang hilang.

Pemeriksa terpisah yang menyebut anomalinya

Kode yang mendeteksi anomali tidak berbagi kode apa pun dengan simulator. Ia membaca hasil eksekusi yang sudah selesai dan mencocokkan setiap anomali dengan definisi yang dipublikasikan. Pemeriksa yang dibangun di atas asumsi simulator akan ikut membenarkan bug simulator. Setiap skenario dites dua arah: anomali wajib muncul di level yang mengizinkannya, dan wajib tidak muncul di level yang mencegahnya.

Alat ini menolak kalau tidak tahu jawabannya

SQL Server memilih transaksi yang dikorbankan saat deadlock berdasarkan perkiraan biaya, jadi jadwal yang sama bisa kehilangan transaksi berbeda di level berbeda. Saya tidak menebak. Aturan itu ditandai belum dimodelkan, dan alat ini menolak menjalankannya sambil menjelaskan alasannya. Sebuah tes memastikan setiap penolakan sesuai dengan deadlock nyata di rekaman. Harness itu juga menangkap satu aturan deadlock yang saya tulis keliru, dan itulah alasan saya membangunnya lebih dulu.

Jadwal dibaca seperti partitur

Transaksi digambar di garis paranada yang sejajar, seperti partitur musik, dengan garis birama di setiap langkah. Membaca lurus ke bawah satu garis birama menunjukkan apa yang terjadi pada saat yang sama. Operasi bisa diseret untuk mengubah urutannya, dan hasilnya langsung diperbarui. Satu tanda merah muncul tepat di langkah ketika anomali tidak lagi bisa dihindari, dengan penjelasan satu kalimat yang dibentuk dari hasil eksekusi. Sebuah matriks menjalankan jadwal yang sama di kelima berkas aturan, di setiap level.

Hasilnya

Isolation Anomaly sudah live dan terbuka untuk umum, dalam bahasa Inggris dan Indonesia, sebagai situs statis penuh. Ada lima mesin yang dimodelkan: PostgreSQL 16, MySQL 8.4, SQL Server 2022, SQL Server 2022 dengan snapshot read aktif, dan Oracle 23ai. Sebelas skenario menunjukkan taruhannya, misalnya jadwal piket untuk write skew dan transfer bank untuk read skew. Anda juga bisa menyusun jadwal sendiri dan membagikannya lewat tautan. Saya membangunnya sendiri dalam dua hari pada Agustus 2026.