Dalam makalah tahun 1995, Kritik Tingkat Isolasi SQL ANSI , Jim Gray and co, mendeskripsikan Phantom Read sebagai:
Oleh karena itu, Phantom Read tidak berarti bahwa Anda dapat dengan mudah mengembalikan snapshot pada awal transaksi yang sedang berjalan dan berpura-pura bahwa memberikan hasil yang sama untuk kueri akan melindungi Anda dari anomali Phantom Read yang sebenarnya.
Dalam implementasi SQL Server 2PL (Penguncian Dua Fase) asli, mengembalikan hasil yang sama untuk kueri yang menyiratkan Kunci Predikat.
Isolasi Snapshot MVCC (Multi-Version Concurrency Control) (salah bernama Serializable di Oracle) sebenarnya tidak mencegah transaksi lain memasukkan/menghapus baris yang cocok dengan kriteria pemfilteran yang sama dengan kueri yang telah dijalankan dan mengembalikan hasil yang ditetapkan dalam menjalankan kami saat ini transaksi.
Untuk alasan ini, kita dapat membayangkan skenario berikut di mana kita ingin menerapkan kenaikan gaji untuk semua karyawan:
- Tx1:
SELECT SUM(salary) FROM employee where company_id = 1; - Tx2:
INSERT INTO employee (id, name, company_id, salary) VALUES (100, 'John Doe', 1, 100000); - Tx1:
UPDATE employee SET salary = salary * 1.1; - Tx2:
COMMIT; - Tx1:
COMMIT:
Dalam skenario ini, CEO menjalankan transaksi pertama (Tx1), jadi:
- Pertama-tama dia memeriksa jumlah semua gaji di perusahaannya.
- Sementara itu, departemen SDM menjalankan transaksi kedua (Tx2) karena mereka baru saja mempekerjakan John Doe dan memberinya gaji 100rb $.
- CEO memutuskan bahwa kenaikan 10% layak dilakukan dengan mempertimbangkan jumlah total gaji, tanpa menyadari bahwa jumlah gaji telah dinaikkan menjadi 100rb.
- Sementara itu, transaksi HR Tx2 dilakukan.
- Tx1 berkomitmen.
Ledakan! CEO telah mengambil keputusan pada snapshot lama, memberikan kenaikan gaji yang mungkin tidak dapat dipertahankan oleh anggaran gaji yang diperbarui saat ini.
Anda dapat melihat penjelasan mendetail tentang kasus penggunaan ini (dengan banyak diagram) di postingan berikut .
Apakah ini Phantom Read atau Tulis Miring ?
Menurut Jim Gray dan rekan , ini adalah Phantom Read karena Write Skew didefinisikan sebagai:
Di Oracle, Manajer Transaksi mungkin atau mungkin tidak mendeteksi anomali di atas karena tidak menggunakan kunci predikat atau kunci rentang indeks (kunci tombol berikutnya) , seperti MySQL.
PostgreSQL berhasil menangkap anomali ini hanya jika Bob mengeluarkan pembacaan terhadap tabel karyawan, jika tidak, fenomena tersebut tidak dicegah.
PERBARUI
Awalnya, saya berasumsi bahwa Serializability akan menyiratkan pemesanan waktu juga. Namun, seperti dijelaskan dengan sangat baik oleh Peter Bailis , pemesanan jam dinding atau Linearizability hanya diasumsikan untuk Strict Serializability.
Oleh karena itu, asumsi saya dibuat untuk sistem Strict Serializable. Tapi bukan itu yang seharusnya ditawarkan oleh Serializable. Model isolasi Serializable tidak menjamin waktu, dan operasi diizinkan untuk diurutkan ulang asalkan setara dengan beberapa eksekusi serial.
Oleh karena itu, menurut definisi Serializable, Pembacaan Phantom seperti itu dapat terjadi jika transaksi kedua tidak mengeluarkan pembacaan apa pun. Namun, dalam model Strict Serializable, yang ditawarkan oleh 2PL, Phantom Read akan dicegah meskipun transaksi kedua tidak mengeluarkan pembacaan terhadap entri yang sama yang kami coba lindungi dari pembacaan hantu.
