Setidaknya ada 2 proses bisnis yang terlibat di sini.
Tampilkan kursi yang tersedia.
Pesan kursi yang dipilih.
Karena proses-proses ini tidak mengikuti satu sama lain secara tidak teratur, dan karena 2 orang dapat memilih kursi yang sama, masalah konkurensi muncul.
Jika desain database Anda memberikan batasan keunikan yang benar sehingga kombinasi dari:
-TheaterID
-SeatID
-EventID
unik, maka database akan mencegah duplikat.
Skenario berikut juga dimungkinkan tetapi akan diatasi dengan implementasi yang disarankan di atas:
Dengan asumsi tampilan grid tersedia untuk teater tertentu dan acara tertentu dapat ditampilkan:
- User1 menampilkan kursi yang tersedia (dan mendapat kursi 1 dan 2)
- User2 menampilkan kursi yang tersedia (dan mendapat kursi 1 dan 2)
- User1 berbicara sedikit dengan pelanggan di telepon
- User2 pergi dan memesan kursi 2 untuk pelanggannya
- User1 mencoba memesan kursi 2 untuk pelanggannya (karena terlihat tersedia di layarnya)
- Indeks unik mencegah langkah 5 dari pengangkutan data.
Jadi semua yang perlu Anda lakukan mungkin tidak lebih dari desain database yang benar dan pilihan yang tepat pada kendala.
Pendekatan lain yang lebih kompleks mungkin dilakukan jika Anda mau, menggunakan antrian transaksi. Dalam hal ini, permintaan dituliskan terlebih dahulu ke antrian kemudian menjalankan proses setiap n detik tetapi itu hampir tidak perlu atau praktis dalam kasus Anda.
Bagian yang sangat menarik adalah apa yang harus ditampilkan oleh grid daftar untuk pengguna 1?