Masalah urus niaga serentak

1.1 Pengenalan

Dan kini keseronokan bermula - teori bagaimana transaksi berfungsi. Bagaimana untuk memastikan sistem berfungsi apabila anda menukar data yang sama dalam urutan yang berbeza? Atau adakah anda ingin melaksanakan satu transaksi dalam transaksi yang lain? Kami akan mula mencari jawapan kepada soalan-soalan ini dengan mengkaji pengasingan transaksi ...

Tahap pengasingan transaksi ialah nilai bersyarat yang menentukan sejauh mana, hasil daripada pelaksanaan transaksi selari secara logik dalam DBMS, data tidak konsisten dibenarkan. Skala tahap pengasingan urus niaga mengandungi beberapa nilai, ditarafkan dari terendah hingga tertinggi; tahap pengasingan yang lebih tinggi sepadan dengan ketekalan data yang lebih baik, tetapi penggunaannya mungkin mengurangkan bilangan urus niaga selari secara fizikal.

Sebaliknya, tahap pengasingan yang lebih rendah membolehkan transaksi yang lebih selari, tetapi mengurangkan ketepatan data. Oleh itu, memilih tahap pengasingan urus niaga yang digunakan, pembangun sistem maklumat, pada tahap tertentu, memberikan pilihan antara kelajuan kerja dan memastikan konsistensi terjamin bagi data yang diterima daripada sistem.

Masalah akses serentak menggunakan transaksi

Apabila urus niaga dilaksanakan secara selari, masalah berikut mungkin berlaku:

• kemas kini hilang - jika satu blok data ditukar secara serentak oleh transaksi yang berbeza, semua perubahan hilang, kecuali yang terakhir;
• Bacaan "kotor" (ms. Bacaan kotor) - membaca data yang ditambah atau diubah oleh transaksi, yang kemudiannya tidak akan disahkan (digulung semula);
• bacaan tidak boleh berulang (ms. bacaan tidak boleh berulang) - apabila membaca semula dalam transaksi yang sama, data yang dibaca sebelum ini ditukar;
• phantom reads - satu transaksi semasa pelaksanaannya beberapa kali memilih banyak baris mengikut kriteria yang sama. Transaksi lain di antara pengambilan ini menambah baris atau mengubah suai lajur beberapa baris yang digunakan dalam kriteria pengambilan transaksi pertama dan berjaya ditamatkan. Akibatnya, ternyata pilihan yang sama dalam transaksi pertama memberikan set baris yang berbeza.

Pertimbangkan situasi di mana masalah ini mungkin berlaku.

1.2 Kemas kini yang hilang

Situasi apabila, apabila satu blok data ditukar secara serentak oleh transaksi yang berbeza, salah satu perubahan hilang.

Katakan terdapat dua transaksi berjalan pada masa yang sama:

Dalam kedua-dua transaksi, nilai medan f2 berubah; setelah selesai, nilai medan mesti dinaikkan sebanyak 45. Malah, urutan tindakan berikut mungkin berlaku:

1. Kedua-dua transaksi membaca keadaan semasa medan secara serentak. Keselarasan fizikal yang tepat tidak diperlukan di sini, sudah cukup bahawa operasi baca kedua mengikut urutan selesai sebelum transaksi lain menulis hasilnya.
2. Kedua-dua urus niaga mengira nilai medan baharu dengan menambah 20 dan 25, masing-masing, pada nilai yang dibaca sebelum ini.
3. Transaksi cuba tuliskan hasil pengiraan kembali ke medan f2. Memandangkan secara fizikalnya mustahil untuk melakukan dua penulisan pada masa yang sama, sebenarnya satu daripada operasi tulis akan dilakukan lebih awal, yang lain kemudian. Operasi tulis kedua akan menimpa hasil yang pertama.

Akibatnya, nilai medan f2, selepas selesai kedua-dua urus niaga, mungkin meningkat bukan sebanyak 45, tetapi sebanyak 20 atau 25, iaitu, salah satu transaksi yang menukar data akan "hilang".

1.3 Bacaan "kotor".

Membaca data yang ditambah atau diubah suai oleh transaksi yang kemudiannya akan gagal untuk dilakukan (rollback).

Katakan kita mempunyai dua transaksi yang dibuka oleh aplikasi berbeza yang melaksanakan pernyataan SQL berikut:

Dalam transaksi 1, nilai medan f2 diubah, dan kemudian dalam transaksi 2, nilai medan ini dipilih. Selepas itu, transaksi 1 digulung semula. Akibatnya, nilai yang diterima oleh transaksi kedua akan berbeza daripada nilai yang disimpan dalam pangkalan data.

1.4 Bacaan tidak berulang

Keadaan apabila, apabila membaca semula dalam transaksi yang sama, data yang dibaca sebelum ini ternyata berubah.

Katakan kita mempunyai dua transaksi yang dibuka oleh aplikasi berbeza yang melaksanakan pernyataan SQL berikut:

Dalam transaksi 2, nilai medan f2 dipilih, kemudian dalam transaksi 1, nilai medan f2 diubah. Jika anda mencuba lagi untuk memilih nilai dari medan f2 dalam transaksi 2, hasil yang berbeza akan diperolehi. Keadaan ini amat tidak boleh diterima apabila data dibaca untuk mengubah suai sebahagiannya dan menulisnya kembali ke pangkalan data.

1.5 Membaca "hantu"

Situasi apabila, semasa membaca berulang dalam transaksi yang sama, pemilihan yang sama memberikan set baris yang berbeza.

Katakan terdapat dua transaksi yang dibuka oleh aplikasi berbeza yang melaksanakan pernyataan SQL berikut:

Transaksi 2 melaksanakan pernyataan SQL yang menggunakan semua nilai medan f2. Kemudian baris baharu dimasukkan dalam transaksi 1, menyebabkan pelaksanaan semula pernyataan SQL dalam transaksi 2 menghasilkan hasil yang berbeza. Keadaan ini dipanggil bacaan hantu (phantom reading). Ia berbeza daripada bacaan tidak boleh berulang kerana hasil capaian data berulang telah berubah bukan disebabkan oleh perubahan/pemadaman data itu sendiri, tetapi disebabkan oleh kemunculan data (hantu) baharu.