Ruby, FXRuby, Ubuntu 9.04

Bulan ini saya mencoba 3 hal yang baru, Ruby, FXRuby, dan Ubuntu 9.04. Setelah instalasi Ubuntu 9.04 selesai, saya langsung mencoba meng-install Ruby dan FXRuby. Setelah sekitar 1 jam mencari paket yang tepat dan men-download-nya, berikut saya rangkum paket-paket apa saja yang perlu di-install:

1. ruby1.8
2. ruby1.8-dev
3. ruby1.8-examples
4. rdoc1.8
5. ri1.8
6. rubygems
7. irb
8. libzlib-ruby
9. build-essential (last but the most! )

Untuk FXRuby:
1. Install paket:
a. libfox-1.6-0
b. libfox-1.6-dev
c. g++
d. libxrandr-dev
2. Install FXRuby dengan gem:
sudo gem install fxruby –remote

Nah, kalau sudah install semua paket tersebut, tinggal test contoh dari situs FXRuby. Horee… Ups! Kok error? Tenang, jangan panik, ada solusinya. Kalau di Window$ anda cukup require ‘fox16′ dan include Fox, maka sekarang anda harus menambahkan require ‘rubygems’ sebelum require ‘fox16′.

Ok, Ruby, here I come….

Multi-User FoxPro with Linux+Dosemu+CIFS

Saya menemukan masih ada beberapa kantor yang menjalankan aplikasi yang ditulis dengan FoxPro. Seperti yang saya alami di kantor saya, kami bahkan masih men-develop beberapa project baru dengan FoxPro, sambil menunggu project migrasi ke Java selesai.

Saat perusahaan kami memutuskan untuk beralih ke Linux, kami pun ditantang untuk dapat menjalankan FoxPro di Linux. Hal yang cukup mudah dilakukan karena adanya Dosemu. Solusi yang dulu kami gunakan yaitu:
1. Data disimpan di satu komputer Linux yang dipasang Samba Server.
2. Pada client diinstall:
a. Dosemu.
b. Samba Client.
3. Di Dosemu di-install FoxPro.
4. Client me-mount data dari server dengan samba:

mount -t smbfs -o rw,username=blabla,password=blabla,uid=1000,gid=1000 //dbfserver/datadir /mnt/datadbf

5. Di autoexec.bat (/home/user/.dosemu/drive_c/autoexec.bat) di line paling akhir, ditambahkan:
lredir d: linux\fs/mnt/datadbf
Sehingga data di server kita akses di dosemu dan foxpro sebagai drive D:

Dengan 1-2 user, konfigurasi ini berjalan dengan mulus. Sampai pada suatu saat terjadi masalah, yaitu index file tidak terupdate dengan benar saat menambahkan record baru. Selain itu muncul juga masalah lain, yaitu update yang dilakukan di satu komputer, tidak terlihat di komputer lain. Hal ini mengindikasikan bahwa 1 file DBF tidak dapat dibuka, apalagi di-update oleh 2 client secara bersamaan. Sehingga, kami terpaksa bekerja secara bergantian.

FIX-1 : veto oplock

Protokol file-sharing di Window$ menggunakan mekanisme locking terhadap file yang sebetulnya lebih mengarah ke ‘caching’, dan Samba mencoba mengikuti standar ini. Artinya secara default, Samba melakukkan caching terhadap file. Ini bukanlah hal yang kita inginkan, sebab dapat mengacaukan program FoxPro.

Jadi, perbaikannya adalah dengan men-disable fitur ini untuk file-file database dan index FoxPro. Tambahkan settingan global ini di /etc/samba/smb.conf :

veto oplock files = /*.dbf/*.DBF/*.idx/*.IDX/*.cdx/*.CDX/*.fpt/*.FPT/

Dengan setting tersebut, sistem pun pulih, untuk sementara. Kemudian terjadi lagi masalah di mana terkadang update oleh satu User tertimpa oleh update User lain. Hal ini dapat disebut sebagai racing condition, yang kembali mengancam integritas data.

FIX-2 : locking dengan flock()

Setelah membaca dokumentasi di FoxPro, saya menemukan bahwa seharusnya program yang dijalankan secara multi-user menggunakan mekanisme locking agar integritas database dapat terjaga. Penggunaan “set exclusive” saja ternyata tidak cukup, maka program pun dirubah dengan menambahkan locking kapanpun akses kritis terhadap database diperlukan.

Anehnya, ternyata locking tidak bekerja, apabila satu user sedang me-lock suatu file, user lain masih dapat me-locknya juga. Jangankan locking dengan flock(), ternyata “set exclusive’ pun tidak bekerja.

FIX-3 : CIFS

Setelah riset dengan mencari sumber di Internet, saya menemukan bahwa SMBFS sudah mulai ditinggalkan karena beberapa bug, dan disebutkan juga bahwa file-locking tidak bekerja di SMBFS. Disarankan untuk beralih ke CIFS, saya pun kemudian melakukan test dengan CIFS ini. Hasilnya, ternyata benar file locking dapat bekerja dengan sempurna.

Command untuk mounting berubah menjadi:
mount -t cifs -o rw,user=blabla,password=blabla,uid=1000,gid=1000,noperms //dbfserver/datadir /mnt/datadbf

Program pun dijalankan lagi dan untuk beberapa waktu dapat berjalan dengan baik. Tampaknya permasalahan belumlah selesai, beberapa kali terjadi kehilangan data. Data yang sudah di-update oleh user, ternyata tidak tersimpan di database.

FIX-5 : nounix and directio

Ternyata meskipun locking dapat bekerja dengan baik, update oleh satu user, tidak dapat dilihat secara langsung oleh user lain. Apabila satu file DBF dibuka secara bersamaan oleh lebih dari satu user, pada saat satu user melakukan perubahan, user lain tidak dapat melihatnya secara langsung. User lain haruslah menutup file DBF tersebut dan membuka nya kembali, barulah update dapat terlihat.

Cara ini tentu tidak nyaman dan menurunkan produktifitas user. Apalagi kami mengalami lonjakan jumlah pengguna program FoxPro ini, dari semula hanya 2 user, hingga saat ini ada hampir 20 user.

Setelah searching di internet, akhirnya saya menemukan kunci dari permasalahan ini, yaitu dengan menambahkan option pada command untuk mounting data.

mount -t cifs -o rw,user=blabla,password=blabla,uid=1000,gid=1000,noperms,nounix,directio

Options nounix dan directio ternyata memecahkan masalah dengan CIFS.

Kesimpulan:

Agar sebuah program FoxPro dapat dijalankan secara multi-user dengan skema Linux+Dosemu+CIFS, ada beberapa “tuning” yang harus kita lakukan dalam sistem. Di antaranya:
1. Menambahkan option veto oplock files terhadap file-file yang berkaitan dengan FoxPro di konfigurasi server Samba.
2. Menggunakan CIFS untuk mounting direktori data, bukan SMBFS.
3. Options mounting dengan CIFS yang digunakan: noperms,nounix,directio
3. Menyesuaikan program, agar melakukan locking saat mengakses data yang akan dirubah.

SMBFS vs CIFS — Part 2

Post ini merupakan lanjutan dari post SMBFS vs CIFS. Setelah saya melakukan investigasi lebih lanjut, saya menemukan hasil yang berbeda dengan yang sebelumnya saya dapatkan. Which is, cukup aneh, dan membuat saya sangat heran. Padahal metode test yang saya lakukan masih sama.

Untuk itu, saya merasa perlu menerangkan secara singkat prosedur test yang saya lakukan:
1. User1 dan User2 adalah 2 (dua) komputer yang berbeda.
2. Mounting dengan CIFS di User1 dan User2.
3. Dibuat satu file DBF untuk ekperimen, kita sebut file tersebut test.dbf.
4. User1 flock() file test.dbf.
5. User2 flock() file test.dbf juga. User2 harusnya diblok dengan pesan ‘Attempting to lock…’
6. User1 update record.
7. User1 unlock file test.dbf.
8. Pada saat yang sama User2 seharusnya keluar dari blok, dan me-lock file test.dbf.
9. User1 dan User2 cek isi record, apakah sudah terlihat hasil update User1 di langkah 6.
10. User2 update record.
11. User2 unlock file test.dbf
12. User1 dan User2 cek isi record, apakah sudah terlihat hasil update User2 di langkah 10.
13. User1 flock() file test.dbf.
14. User1 dan User2 cek isi record, bandingkan dengan hasil di langkah 12.

Hasil yang sudah saya dapatkan sebelumnya menunjukkan bahwa dengan CIFS kita dapat me-lock suatu file DBF di FoxPro, namun update oleh satu user tidak dapat dilihat oleh user lain sekalipun file sudah di-lock. Dengan membuka ulang file DBF-nya dengan “use”, barulah perubahan tersebut dapat kita lihat. Terlepas dari apakah kita me-lock file-nya atau tidak.

Hasil test terbaru yang saya lakukan, menyimpulkan bahwa dengan locking, update bisa terlihat secara langsung, tanpa perlu membuka ulang DBF dengan use. Kemungkinan perubahan ini diakibatkan oleh mount options yang berbeda. Kebetulan saya mendapatkan informasi dari arsip suatu milis yang saya lupa namanya. Dengan menambahkan nounix dan directio sebagai mount options, sepertinya membuat perbedaan antara hasil test pertama dengan hasil test kedua.

Namun, syarat agar perubahan tersebut dapat dilihat secara langsung oleh user lain, ada 2 cara:
1. Dengan ‘go top’ dahulu kemudian ‘goto’ record yang dimaksud. Atau dengan kata lain, kita pindah ke record yang lain dahulu kemudian kembali ke record yang semula. Update dapat dilihat.
2. Dengan mekanisme locking dengan flock() seperti langkah-langkah test yang saya sebutkan di atas.

Cara yang terbaik tentu saja dengan mekanisme locking dengan flock(), sesuai anjuran FoxPro di Help page nya.