Implementasi Optimistic Locking pada JDBC

[S]elamat datang pembaca!. Semoga tetap diberi kesehatan di musim penghujan yang ekstrem ini. Di kesempatan ini saya mau share suatu topik tentang implementasi Optimistic Locking di Jdbc (Java Database Connectivity). Diharapkan pembaca sudah familiar dengan teknologi Jdbc minimal sudah pernah coding Jdbc sendiri pakai tangan sendiri ๐Ÿ˜€

Optimistic Locking

Apa itu Optimistic Locking?
Biar gampang dipahami saya coba pakai pendekatan studi kasus. Misal ada suatu aplikasi Inventory Buku yang bisa diakses oleh beberapa user secara bersamaan. Kronologinya adalah sebagai berikut.

User A (disingkat A) dan User B (disingkat B) melakukan kegiatan berikut dengan waktu hampir bersamaan.

A mengambil data buku dengan ID=1 (judul=”Arus Balik”)
B mengambil data buku dengan ID=1 juga (judul=”Arus Balik”)

A mengganti judul buku menjadi “Arus Bolak Balik”
B mengganti judul buku menjadi “Arus Balik Lagi”

A melakukan save perubahan data dan berhasil
B melakukan save perubahan data namun gagal dan muncul pesan bahwa data sudah diubah

Data judul buku dengan ID=1 pada database sekarang adalah “Arus Bolak Balik”

Seperti itulah yang dimaksud dengan Optimistic Locking. Ketika ada data yang akan diubah oleh beberapa orang secara bersamaan maka data yang pertama tersimpanlah yang valid. Hal ini berkebalikan dengan Pessimistic Locking.

Apa pula itu Pessimistic Locking?
Lagi. Menggunakan contoh studi kasus seperti di atas agar mudah dimengerti.

A mengambil data buku dengan ID=1 (judul=”Arus Balik”)
B mengambil data buku dengan ID=1 juga (judul=”Arus Balik”)

A mengganti judul buku menjadi “Arus Bolak Balik”
B mengganti judul buku menjadi “Arus Balik Lagi”

A melakukan save perubahan data dan berhasil
B melakukan save perubahan data dan berhasil juga

Data judul buku dengan ID=1 pada database sekarang adalah “Arus Balik Lagi”

Jadi data yang tersimpan adalah data yang terakhir disave, istilahnya Last Commit Win.

Cukup dengan teori sekarang ke implementasi. Secara default, dari sononya, Pessimistic Locking adalah yang terjadi. Jadi untuk teknik ini tidak perlu pembahasan lebih lanjut. Sesuai judul, kita bahas implementasi Optimistic Locking pada Jdbc.

Beberapa hal yang perlu diperhatikan adalah:
-Program harus tahu bahwa data sudah pernah diubah
-Data memerlukan sebuah Flag sebagai tanda bahwa sudah pernah diubah

Salah satu tanda yang digunakan adalah dengan menambahkan kolom “versi” pada suatu tabel. Kolom ini bernilai mula-mula 1 saat data baru dimasukkan dan setiap ada update data maka nilainya akan ditambah 1 secara incremental.

Pada method update jika biasanya syarat yang digunakan adalah kolom “id” maka untuk Optimistic Locking perlu ditambah syarat “versi” tadi.

biasa/pessimistic locking

optimistic locking

Dengan cara seperti ini maka program akan mengetahui bahwa versi sudah berubah atau belum. Jika versi sudah berubah maka perintah UPDATE hanya akan mengembalikan baris sejumlah 0 karena tidak ada kondisi yang memenuhi persyaratan.

Mari kita kembali ke contoh kasus di atas dan telaah

Saat ini di database data buku dengan id=”1″ berjudul=”Arus Balik” versi=”1″

A mengambil data buku dengan ID=1 (judul=”Arus Balik”;versi=”1″)
B mengambil data buku dengan ID=1 juga (judul=”Arus Balik”;versi=”1″)

A mengganti judul buku menjadi “Arus Bolak Balik”
B mengganti judul buku menjadi “Arus Balik Lagi”

A melakukan save perubahan data dan berhasil
Saat ini di database data buku dengan id=”1″ berjudul=”Arus Balik” versi=”2″

B melakukan save perubahan data namun gagal dan muncul pesan bahwa data sudah diubah
Terjadi karena data pada B masih berversi=”1″, ketika dicocokkan ke database adakah data dengan id=”1″ dan versi=”1″ maka tidak akan memenuhi syarat karena data sudah menjadi id=”1″ versi=”2″

Data judul buku dengan ID=1 pada database sekarang adalah “Arus Bolak Balik” dengan versi=”2″

Berhubung semua sudh jelas, terang benderang tidak ada mendung atau gelap secuilpun :p maka implementasi Optimistic Locking pada Jdbc adalah seperti ini

Pada baris yang saya highlight :
24-25 adalah pernyataan untuk menyimpan data buku ke database di mana di sana terlihat nilai untuk kolom “versi” adalah selalu 1.

34-35 pernyataan untuk mengupdate data buku dengan persyaratan menggunakan kolom “id” dan “versi”. Di situ juga nampak kalau data pada kolom “versi” akan ditambah 1 nilainya.

41-45 merupakan kondisi untuk mengecek apakah data sudah berubah atau belum. Data sudah berubah ditandai dengan 0 data yang terksekusi perintah sql. Exception yang dilempar adalah kelas buatan sendiri yang merupakan child class dari Exception

Sekarang coba tes pakai integration tes dengan bantuan JUnit atau dengan cara konvensional di method main. Saya punya data contoh seperti ini
arus balik

Berikut kode yang saya gunakan untuk menguji

Jalankan test case di atas

Dan berhasil, artinya kode sudah berfungsi sebagaimana mestinya. Kalau masih kurang puas silahkan lihat data pada database, data pertamakah atau keduakah yang masuk.

arus balik dua

Terbukti data pertama yang disimpan, data kedua dibuang ke TPA hahaa..

Demikian sharing sedikit ilmu yang saya miliki, semoga bermanfaat dan salam programming ๐Ÿ˜€

sample code bisa di didownload di github:
https://github.com/blinkawan/Optimistic-Locking-JDBC-Sample

[followme]

Facebook Comments
 

Agung Setiawan

Agung Setiawan adalah software engineer di BukaLapak.com, penulis sekaligus pecinta sastra, dan pembaca buku

 
Halo, perkenalkan saya Agung Setiawan.
Saya Software Engineer di BukaLapak.
Simak pemikian saya soal dunia Software Engineering via Twitter di @agungsetiawanmu dan facebook
Blog ini saya update seminggu sekali jadi sering-sering saja mampir
Mau belajar Vim bareng saya?
Belajar ngoding dari nol menggunakan PHP

Leave a Reply

Your email address will not be published. Required fields are marked *