Konkurensi Optimis: Gambaran Umum

LINQ ke SQL mendukung kontrol konkurensi optimis. Tabel berikut ini menjelaskan istilah yang berlaku untuk konkurensi optimis dalam dokumentasi LINQ ke SQL:

Syarat Deskripsi
keserempakan Situasi di mana dua atau beberapa pengguna pada saat yang sama mencoba memperbarui baris database yang sama.
konflik konkurensi Situasi di mana dua atau beberapa pengguna pada saat yang sama mencoba mengirimkan nilai yang bertentangan ke satu atau beberapa kolom baris.
kontrol konkurensi Teknik yang digunakan untuk mengatasi konflik konkurensi.
kendali konkurensi optimis Teknik yang pertama kali menyelidiki apakah transaksi lain telah mengubah nilai secara berturut-turut sebelum mengizinkan perubahan dikirimkan.

Kontras dengan kontrol konkurensi pesimis yang mengunci catatan untuk menghindari konflik konkurensi.

Kontrol optimis begitu istilahnya karena menganggap kemungkinan satu transaksi yang mengganggu transaksi lain tidak mungkin terjadi.
resolusi konflik Proses penyegaran item yang bertentangan dengan mengkueri database lagi lalu mendamaikan perbedaan.

Saat objek di-refresh, pelacak perubahan LINQ ke SQL menyimpan data berikut:

- Nilai awalnya diambil dari database dan digunakan untuk pemeriksaan pembaruan.
- Nilai database baru dari kueri berikutnya.

LINQ ke SQL kemudian menentukan apakah objek bertentangan (yaitu, apakah satu atau beberapa nilai anggotanya telah berubah). Jika objek berkonflik, LINQ ke SQL selanjutnya menentukan anggotanya mana yang bertentangan.

Setiap konflik anggota yang ditemukan LINQ ke SQL ditambahkan ke daftar konflik.

Dalam model objek LINQ ke SQL, konflik konkurensi optimis terjadi ketika kedua kondisi berikut ini benar:

  • Klien mencoba mengirimkan perubahan ke database.

  • Satu atau beberapa nilai pemeriksaan pembaruan telah diperbarui dalam database sejak klien terakhir kali membacanya.

Penyelesaian konflik ini termasuk menemukan anggota objek mana yang berkonflik, lalu memutuskan apa yang ingin Anda lakukan tentang hal tersebut.

Nota

Hanya anggota yang dipetakan sebagai Always atau WhenChanged berpartisipasi dalam pemeriksaan konkurensi optimis. Tidak ada pemeriksaan yang dilakukan untuk anggota yang ditandai Never. Untuk informasi selengkapnya, lihat UpdateCheck .

Contoh

Misalnya, dalam skenario berikut, User1 mulai menyiapkan pembaruan dengan mengkueri database untuk baris. User1 menerima baris dengan nilai Alfreds, Maria, dan Sales.

User1 ingin mengubah nilai kolom Manajer menjadi Alfred dan nilai kolom Departemen menjadi Pemasaran. Sebelum Pengguna1 dapat mengirimkan perubahan tersebut, Pengguna2 telah mengirimkan perubahan ke database. Jadi sekarang nilai kolom Asisten telah diubah menjadi Maria dan nilai kolom Departemen menjadi Layanan.

Ketika User1 sekarang mencoba mengirimkan perubahan, pengiriman gagal dan ChangeConflictException pengecualian dilemparkan. Hasil ini terjadi karena nilai database untuk kolom Asisten dan kolom Departemen bukan yang diharapkan. Anggota yang mewakili kolom Asisten dan Departemen berkonflik. Tabel berikut ini meringkas situasi.

Negara Manajer Asisten Departemen
Keadaan asli Alfreds Maria Sales
Pengguna1 Alfred Marketing
Pengguna2 Maria Pelayanan

Anda dapat mengatasi konflik seperti ini dengan cara yang berbeda. Untuk informasi selengkapnya, lihat Cara: Mengelola Konflik Perubahan.

Daftar Periksa Deteksi konflik dan Resolusi

Anda dapat mendeteksi dan mengatasi konflik pada tingkat detail apa pun. Pada satu ekstrem, Anda dapat menyelesaikan semua konflik dengan salah satu dari tiga cara (lihat RefreshMode) tanpa pertimbangan tambahan. Pada ekstrem lainnya, Anda dapat menunjuk tindakan tertentu untuk setiap jenis konflik pada setiap anggota yang berkonflik.

LINQ ke Jenis SQL yang Mendukung Penemuan dan Resolusi Konflik

Kelas dan fitur untuk mendukung penyelesaian konflik dalam konkurensi optimis di LINQ ke SQL meliputi:

Lihat juga

  • Last updated on