MultiUser Application (1)

Posting ini ter-ilhami dari beberapa projek yang saya develop beserta permasalahan umum dan penyelesaiannya. (setidaknya cara penyelesaian yang telah saya lakukan )

Sering kali ketika membanguan aplikasi untuk banyak user muncul kejadian data konflik ketika multiple user tersebut mencoba untuk membuat transaksi konkuren terhadap Database. Transaksi adalah mekanisme yang dilakukan oleh suatu aplikasi terhadap database, sedangkan Konkuren merupakan keadaan simultan terhadap pelaksanaan transaksi yang ada. Pada dasarnya, penanganan konkurensi mengacu pada transaction locking, dan (biasanya) melakukan unique key.
Dasar Pendekatan metode transaction locking pada sebagaian provider database dan datasource kontrol pada sejumlah aplikasi (ADO, ADO.NET) berdasar pada teori pesimistik locking konkuren, optimistik locking konkuren dan pendekatan last in win.

Pesimistik Konkurensi, merupakan metode penguncian transaksi yang mengunci sebuah row dari table dalam sebuah data source yang terhubung ke table database, dengan tujuan untuk mencegah manipulasi data yang akan mempengaruhi transaksi ke user lain, user lain tidak bisa melakukan transaksi lain sampai kuncian melalui metode ini dilepaskan. Secara teori pesimistik konkuren ini tidak skalable untuk user yang selalu berinteraksi secara intensif dengan data karena akan menyebabkan database engine akan terkunci untuk periode dan kurun waktu yang lama, sama halnya pendekatan ini tidak cocok untuk disconnected architechture, koneksi akan selalu terbuka untuk jangka waktu yang cukup lama untuk sebuah transaksi DDL atau DML saja.

Optimistik Konkurensi, merupakan teori locking yang menggunakan pendekatan tidak mengunci row ketika sedang terjadi pembacaan data, the application must determine whether another user has changed the row since the application read the row, If another user has changed the row, the application rejects the current update to preserve the changes by other user.

Last In Wins, teori ini lebih extreme dari pada optimistik, aplikasi yang menggunakan pendekatan ini tidak melakukan pengecekan kepada original data ketika sedang ingin mengupdate database,
the application will overwrite with new data any existing values in the row that is updating. seperti contoh skenatio di bawah :
User X membaca record dari database
User Y membaca record yang sama dari database, kemudian memodifikasinya serta mengupdatenya
User X mengupdate record yang lama dan menuliskannya kembali ke dalam database. dimana user X tidak menyadari akan perubahan yang telah dilakukan oleh user Y.
Pendekatan saling overwrite ini tidak cocok utk production application.

Advertisement