Tanggal Sebelumnya Tanggal Berikutnya Ulir Sebelumnya Ulir Berikutnya
Indeks - Tanggal Indeks - Ulir Diskusi
| From | "Ikhlasul Amal" <amal @ somewhere.in.the.world> |
| Date | Tue, 22 May 2001 23:49:20 +0700 |
| Organization | Kampung Angin Berdesir |
[Mon, 21 May 2001, 09:41:56 +0700 4.3K] Darwis Fadhli menulis (diedit):
% nah.. mengkin untuk sedikit mempertajam pertanyaan Om Santos.. saya
% juga mau bertanya..
% kira2 bisa gak kita melakukan proses checking status perubahan data
% pada database
% tanpa harus melakukan proses requery terus menerus menggunakan timer
% atau komponen apapun...
% yang bersifat meng-query ulang data setiap n-waktu..
% karena saya pikir proses ini sangat memberatkan server, apalagi kalau
% kita berurusan dengan
% real time data yang ordernya dibawah 1 detik..
%
---end quoted text---
[ PERHATIAN: Tulisan panjang berikut mengulas teknik
Producer/Consumer. Apabila saudara TIDAK menyukai tulisan
non-fiksi ilmiah, sebaiknya lewati saja ]
Kalau ordenya di bawah satu detik, bahkan cron saja menyerah.
Satuan terkecil cron 1 menit. Jadi harus digunakan daemon dan
cara memandangnya dibalik: daripada basisdata dilihat statusnya
dengan jalan query berulang-ulang ('pooling'), lebih baik
biarkan dia bekerja dan pada kondisi tertentu yang diinginkan,
buat sinyal. Ini algoritma penjaja bakso: alih-alih kita
mondar-mandir di beranda rumah menunggu mereka lewat
('pooling'), lebih baik kita pasang pendengar ('listener')
sampai denting sendok mengenai mangkok terdengar ('interrupt').
Saya kurang menguasai lingkungan basisdata secara mendalam
(Darwis faham soal ini!); yang saya tahu di lingkungan
pemrosesan, terutama dipraktekkan dalam sistem operasi, terdapat
konsep untuk kasus di atas yang dikenal dengan nama
'Producer/Consumer' (P/C). Jadi apabila terdapat dua proses yang
secara simultan berjalan bersama dan satu menghasilkan sementara
lainnya mengambil hasilnya, maka teknik sinkronisasi salah
satunya adalah P/C. Seingat saya, buku legendaris "Operating
System", Andrew Tanenbaum (Prentice-Hall), termasuk yang
mengulas teknik ini untuk sistem operasi.
Pada intinya kurang lebih begini: si Producer bersifat menulis
sementara Consumer membaca tulisan itu dan *memastikan* bahwa
tulisan itu sudah terbaca, supaya tidak dilakukan pembacaan data
terulang. Pada versi Produser/Consumer yang jamak (lebih dari
satu), bentuk yang lebih kompleks adalah algoritma tiket
('ticketing').
Oke, itu semua teori; untuk basisdata yang dikemukakan Darwis,
maka RDBMS menjadi Producer dan dia menulis status ('updated'
misalnya) di sebuah tempat yang terbaca bersama ('shared area').
Seperti yang telah disebutkan oleh Asep Abdurrahman, gunakan
saja pemicu ('trigger') di RDBMS untuk keperluan itu, sehingga
hemat dan tepat-keperluan. Yang saya tidak tahu, bagaimana cara
pembuatan 'shared area' di lingkungan RDBMS, namun minimal bisa
ditulis dalam bentuk file reguler, seperti halnya yang banyak
dibuat oleh aplikasi di /var/run di Linux. Karena hanya berupa
status, seharusnya file ini sangat kecil dan tidak terlalu
membebani performansi sistem.
Di tempat lain dipasang program pendengar ('listener') yang
menjadi daemon untuk memeriksa perubahan status di atas. Kalau
dibaca di perlipc ($ man perlipc) rasanya tidak terlalu sulit
membuat operasi soket untuk client/server (lihat bagian "Socket:
Client/Server Communication"). Nah, daemon kecil ini mengatasi
masalah supaya kita tidak 'query' berkali-kali ke basisdata
hanya untuk mengetahui bahwa basisdata termutakhirkan
('updated'). Koneksi ke soket juga relatif murah ongkosnya dan
cukup diatasi oleh modul kecil menggunakan C atau Java.
Untuk menjelaskan bahwa status terakhir sudah dibaca Consumer,
maka setiap selesai dibaca, Consumer perlu mengubah status pada
'shared area', sehingga pada pembacaan berikutnya tidak dianggap
terdapat pemutakhiran basisdata lagi. Operasi ini pun bisa
diserahkan kepada daemon di atas. Teknik ini juga tidak terlalu
sulit, dan salah satu contoh yang sudah diterapkan adalah
perubahan kata sandi ('password') lewat port POP3/110 dari
klien-email Eudora ke Linux. Saya lupa nama modulnya, kalau
tidak salah poppassd (?), waktu itu saya memperolehnya sebagai
'hadiah' dari Mas Andika Triwidada untuk keperluan pembuatan
aplikasi perubahan kata-sandi lewat Web.
Jadi selama 'pooling' berlangsung dengan frekuensi tinggi yang
dilakukan adalah memborbardir port sekedar untuk melihat status
basisdata. Menurut hemat saya, ini tidak akan menjadi masalah,
toh, aplikasi C/S memang perlu koneksi kontinu. 'Query' hanya
dilakukan jika memang status basisdata mengalami perubahan.
Itu yang saya ketahui. Apabila terdapat salah kata atau
penggunaan istilah, sila dikoreksi.
--
amal
Ayo tersenyum: negeri ini memerlukannya
Attachment:
pgpXI8xWbBrDq.pgp
Description: PGP signature
Dihasilkan pada Thu Sep 22 18:41:56 2005 | menggunakan mhonarc 2.6.10