Hindari Pengulangan Kode, Gunakan Function / Method

Salah satu dari banyaknya hal yang sering dilakukan coder adalah, mengulai pembuatan kode yang sama berulang kali. Hal ini bukan hanya membuat kode jadi lebih panjang, tapi juga lebih sudah dibaca dan lebih membosankan, bahkan sulit di refactor kalo suatu saat ada perubahan. Contohnya seperti kode berikut yang sering kita lakukan.

	var jenisKelamin = "L";
	if (jenisKelamin == "P") {
	console.log("Wanita");
	} else if (jenisKelamin == "L") {
	console.log("Pria");
	} else {
	console.log("Bencong :P");
	}

view raw

app-run.js

hosted with ❤ by GitHub

Pessimistic VS Optimistic Locking

guys, malam ini saya mau bagi2 daging (baca: ilmu) nih, seputar database, pessimistic dan optimistic locking.

#PessimisticLocking

langsung aja ke contoh kasus:
– ada sebuah aplikasi inventory, dimana bisa diakses oleh beberapa user secara bersamaan
– misal saat ini sedang diakses oleh 2 user, user A dan user B

mereka berdua melakukan hal ini secara bersamaan :

A meload data barang dengan id 001 (nama: Dodol)
B meload data barang dengan id 001 (nama: Dodol)

A mengubah nama barang (id 001) menjadi Dodol Garut
B mengubah nama barang (id 001) menjadi Dodol Subang

A refresh data barang, yang didapat Dodol Subang 😦
B refresh data barang, yang didapat Dodol Subang 😀

kasus diatas dinamakan pessimistic locking, yang artinya siapa yang terakhir mengubah data barang, maka dia yang menang! #yeah!!!

apakah ada yang salah? sebenarnya gak ada yang salah, cuma secara kode etik (alah ngomong apa sih) sebenarnya bermasalah, ketika sebelum si B mengubah nama barang menjadi Dodol Subang, dia seharusnya tahu kalo nama barang telah berubah ke Dodol Garut, dengan begitu ada kemungkinan dia tidak akan jadi mengubah data nama barang tersebut.

#OptimisticLocking

berbeda dengan pessimistic locking, di Optimistic Locking, siapa yang mengubah pertama kali, maka dialah yang menang, yang terakhir mengubah, dia harus tahu dulu kalo sudah terjadi perubahan.

Jadi jika menggunakan Optimistic Locking kejadiannya akan seperti ini :

A meload data barang dengan id 001 (nama: Dodol)
B meload data barang dengan id 001 (nama: Dodol)

A mengubah nama barang (id 001) menjadi Dodol Garut
B mengubah nama barang (id 001) menjadi Dodol Subang

B mendapatkan error, dan diberitahu kalo data sudah berubah
A senang 😀

#Contoh
berikut adalah contoh framework yang support optimistic locking :
– Hibernate Framework
– Java Persistence API
– …. silahkan sebutkan di komentar 😀

Blocking IO vs NonBlocking IO

pernah denger blocking io dan non blocking io? yuk kita bahas sekarang 

‪#‎BlockingIO‬

atau dikenal juga dengan synchronous io. dalam blocking io sebuah proses akan dilaksanakan jika proses sebelumnya telah selesai dilaksanakan.

rata2 semua web server dan web framework sekarang itu blocking io.

dalam server blocking io, biasanya punya maksimal kapasitas queue, misal jika max queue = 300, sedangkan pada saat yang bersamaan terdapat 1000 request, maka otomatis 700 request akan ditahan, sampai 300 request pertama selesai dilaksanakan, hal ini membuat respon server terlihat lambat sekali, karena harus menunggu proses pertama selesai.

‪#‎NonBlockingIO‬

berbeda dengan blocking io, non blocking io biasa disebut juga dengan asynchronous io. dalam non blocking io, setiap request akan dilaksakan langsung tanpa harus menunggu request yang lain selesai dilaksanakan.

dalam non blocking io, setiap proses akan langsung dikembalikan, tanpa harus menunggu proses selesai. lantas bagaimana mendapat hasilnya jika proses belum selesai sedangkan sudah dikembalikan? non blocking io akan mengirim hasil melalui callback/listener

‪#‎Contoh‬
berikut adalah contoh framework yang menggunakan non blocking io :
– Netty
– Akka
– Play Framework
– NodeJS
– … (silahkan tambahkan yang lain di komen)

‪#‎SemogaBermanfaat‬