tableyang menyimpan data status monitor dan approve pada row tertentu. Ini akan mencegah data tertumpuk atau kesalahan pengisian data lainnya.
Sistem monitoring ini akan diuji coba di PT. PLN Persero Area Kuala Kapuas, dimana pengguna sistem adalah staff yang berada disana. Pengujian
dilakukan dengan menguji sistem pada bagian lihat data, upload data, ubah data, hingga proses pembatalan status monitor dan approve. Setelah uji sistem,
pengguna akan mengisis kuisioner untuk mengetahui sejauh mana sistem ini membantu proses monitoring yang dilakukan disana.
5.2. Analisa Hasil Uji Coba Terhadap Program
Untuk menguji manajemen transaksi yang diimplementasikan pada mesin di sistem monitoring ini, maka Penulis melakukan uji coba dengan menjalankan
simulasi dimana dilakukan 2 transaksi yang menerapkan metode 2PL Two Phase Locking. Simulasi ini dilakukan untuk menjawab permasalahan lost of update
yang terjadi pada saat upload data, ubah data, approve maupun proses pembatalan yang berlangsung bersamaan. Kedua transaksi yang mengakses row yang sama
pada tabel akan diberikan delay untuk membuat agar keduanya saling bertabrakan. Transaksi yang berjalan lebih dulu otomatis akan menjalakan teknik lock untuk
menguci row yang diaksesnya agar transaksi lain tidak dapat melakukan write data pada row tersebut. Uji coba ini dilakukan dengan menggunakan 2 browser
yaitu Google Chrome untuk transaksi 1 dan Mozilla Firefox untuk transaksi 2. Berikut ini akan dijelaskan dalam subbab 5.2.2 dan 5.2.3.
5.2.1. Pengujian Kasus The Lost of Update Problem
5.2.1.1. Pengujian Terhadap Proses Approve dan Ubah Data Monitoring
Pelanggan kWh0 A.
Dengan Manajemen Transaksi 2PL
Berikut ini akan dijelaskan simulasi pengujian proses approve data pelanggan kwh 0 transaksi 1 yang pada saat bersamaan ada transaksi 2 yang akan
melakukan ubah data monitoring pelanggan tersebut. Transaksi 1 dijalankan oleh admin area dan transaksi 2 dijalankan oleh admin rayon.
Gambar 5. 1 Alur proses monitoring pelanggan
Aturan untuk mendapatkan IDMON saat mengubah data monitoring adalah belum memiliki status approve artinya kolom status_app di tabel DLPD_PASCBAYAR
bernilai null. Ketika transaksi lain transaksi 1 yang mendahului transaksi ubah data ini melakukan locking terhadap row tersebut, maka transaksi ubah data
transaksi 2 tidak dapat melakukan ubah data karena status approve yang PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
sekarang sudah bernilai „YES‟. Untuk diagram simulasi percobaan dapat dilihat pada gambar 5.2.
Gambar 5. 2Diagram simulasi percobaan 1
Untuk langkah simulasi akan ditunjukan pada gambar 5.3 sd gambar 5.13 berikut ini:
1. Proses melihat daftar pelanggan belum approve pada transaksi 1 ditunjukan
pada gambar 5.3 yang ditunjuk anak panah. Data pelanggan yang akan diapprove oleh transaksi 1 adalah data pelanggan dengan idpel
225000006829. Pada saat yang bersamaan transaksi 2 juga akan melakukan ubah data terhadap pelanggan tersebut, ditunjukan pada gambar 5.4 yang
ditunjuk oleh anak panah. 2.
Transaksi 1 dan 2 akan mengklik tombol pada kolom lihat detail untuk melihat detail monitoring pelanggan tersebut. Pada gambar 5.5 ditunjukan bahwa
transaksi 1 akan melakukan approve dengan mengklik tombol APPROVE. Sedangkan transaksi 2 gambar 5.6 akan mengubah data pelanggan tersebut
pada bagian keadaan MCB, koordinat, tanggal monitoring berikut dengan verifikasinya.
Gambar 5. 3 Data pelanggan kwh 0 belum apporve transaksi 1
Gambar 5. 4 Data pelanggan kwh 0 sudah cek transaksi 2
Gambar 5. 5 Halaman lihat detail pelanggan untuk proses approve transaksi 1
Gambar 5. 6 Halaman isian untuk ubah data monitoring pelanggan transaksi 2
3. Pada simulasi ini stored procedure untuk approve data akan diberi delay
untuk menunggu agar transaksi 2 berjalan bersamaan dengan transaksi 1.Pemanggilan stored procedure ini dimaksudkan untuk mencegah masalah
lost of update dimana data yang akan diapprove akan berubah ketika proses ubah data yang berjalan setelahnya transaksi 2 telah commit terlebih
dahulu sebelum proses approve oleh transaksi 1selesai. Pemberian delay ini dilakukan dengan memberi perintah DBMS_LOCK.SLEEP number in
seconds setelah perintah locking. DMBS_LOCK.SLEEP ini akan membuat delay selama waktu yang ditentukan. Berikut ini pada gambar 5.7 adalah
potongan stored procedure approve_pascabayar dengan menggunakan perintah DBMS_LOCK.SLEEP :
Gambar 5. 7 Prosedur approve_pascabayar dengan
DBMS_LOCK.SLEEP selama 20 detik 4.
Delay pada gambar 5.7 akan mengakibatkan kedua transaksi bertabrakan sehingga protokol 2PL akan dijalankan. Pada saat transaksi 1 mengklik
tombol APPROVE pada gambar 5.5 dibawah ini, maka delay akan dijalankan setelah proses locking berhasil dilakukan pada data pelanggan
tersebut. Transaksi 2 juga mengklik tombol UBAH DATA gambar 5.6 dan akan menjalankan prosedur monitor_pascabayar.
5. Transaksi 1 yang lebih dulu menjalankan lock maka akan diberi
kesempatan untuk write pada kolom status_app dan idmon di tabel DLPD_PASCABAYAR. Transaksi 2 yang berjalan setelahnya akan
berada dalam status wait. Pada gambar 5.8 dan 5.9 diperlihatkan kedua transaksi masih dalam status menunggu karena delay 30 detik yang
diberikan pada prosedur approve_pascabayar pada transaksi 1.
Gambar 5. 8 transaksi 1 akan klik tombol APPROVE untuk melakukan approve
pada data tersebut PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 9 Transaksi 2 mengubah data koordinat, verifikasi, tanggal monitor,
dan keadaan MCB pada data pelanggan diatas 6.
Transaksi 1 berhasil melakukan approve pada data pelanggan tersebut. Hal ini ditunjukan pada gambar 5.10 dimana terdapat pesan bahwa data
monitoring telah di-approve. Sedangkan pada transaksi 2 gambar 5.11 terjadi kegagalan ubah data dimana terdapat pesan data tidak berhasil
disimpan,silakan cek kembali. Karena kedua transaksi bertabrakan, transaksi 1 berhasil melakukan lock , sehingga transaksi 2 harus menunggu
transaksi 1 untuk melepas lock tersebut. Transaksi 2 dalam status WAIT. Setelah transaksi 1 melepas lock, status approve data tersebut berubah
menjadi YES. Pada prosedur monitoring_pascabayar untuk menyimpan data perubahan pelanggan, terdapat fungsi tambah_idmon_pasca yang
akan mengecek status monitoring dan approve dari data tersebut. Ada sebuah kondisi gambar 5.12 dimana jika status approve tidak sama
dengan null maka pemberian idmon tidak dapat dilakukan. Karena hasil keluaran fungsi ini bernilai null maka prosedur tidak dapat menjalankan
perintah lainnya. Prosedur akan melakukan rollback untuk mengembalikan data ke keadaan semula. Inilah yang menyebabkan data tidak dapat diubah
setelah diapprove. Halaman pada gambar 5.4 akan dimuat ulang, setelah mengklik tombol kembali data pelangan pada halaman daftar berubah
statusnya menjadi sudah diapprove gambar 5.13.
Gambar 5. 10 Transaksi 1 sukses
Gambar 5. 11 Transaksi 2 gagal
Gambar 5. 12 Kutipan fungsi tambah_idmon_pasca jika v_status_app tidak null
maka idmon = null PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 13 Daftar pelanggan kwh 0 sudah cek dimana status monitor idpel
225000006829 berubah menjadi sudah approve
B. Tanpa Manajemen Transaksi 2PL
Jika sebelumnya telah dilakukan simulasi untuk menangani masalah lost of update dengan menggunakan method 2 phase locking, maka pada simulasi ini Penulis ini
menunjukan kasus transaksi 1 approve data A yang akan disela dengan transaksi 2 ubah data A menjadi B. Tanpa adanya 2PL maka data yang diapprove oleh
transaksi 1 bukan lagi data A melainkan data B. Yang dimaksudkan disini adalah id monitoring idmon sebagai id untuk referensi data sebelumnya yang berubah
ketika approve disela dengan ubah data. Ini akan menyebabkan data menjadi tidak konsisten.
1. Data yang akan diapprove adalah data dengan idpel
225000010899
dengan blth 201401. Transaksi 1 akan mengakses halaman kwh-0-detail-approve
sedangkan transaksi 2 akan mengakses halaman kwh0-sudah-cek yang ditunjukan pada gambar 5.14 dan 5.15.
Gambar 5. 14 Transaksi 1 yang akan approve data
Gambar 5. 15 Transaksi 2 yang akan mengubah data yang akan diapprove oleh
transaksi 1 2.
Untuk membuat agar kedua transaksi ini bertabrakan, maka sama seperti ujicoba sebelumnya, delay selama 20 detik akan dibuat untuk transaksi 1
sehingga transaksi
2 dapat
menyela. Pada
stored procedure
approve_pascabayar klausa FOR UPDATE OF akan dihilangkan agar tidak ada proses locking yang terjadi gambar 5.16.
Gambar 5. 16 Klausa FOR UPDATE OF dihapus,delay diset 20 detik
3. Transaksi 1 akan mengklik tombol APPROVEdan akan terjadi delay
selama 20 detik, disisi lain transaksi 2 juga mengubah data dan mengklik tombol UBAH. Namun, karena tidak ada delay yang dipasang pada
transaksi 2 maka transaksi berjalan lancar dan data berhasil disimpan gambar 5.17. Pada pembahasan A seharusnya proses ubah data ini tidak
boleh commit berhasil karena status approve untuk data tersebut telah berubah menjadi YES yang artinya ubah data tidak diperkenankan lagi.
Gambar 5. 17Transaksi 2 berhasil melakukan ubah data
4. Transaksi 1 masih menunggu, setelah delay selesai maka dbms akan aktif
kembali, transaksi 1 berhasil dan muncul pesan data berhasil diapprove gambar 5.18. Namun, setelah melihat data detail approve-nya Petugas
akan menyadari bahwa detail monitoring dari data yang diapprove telah berubah itulah maksud dari data A yang diapprove, berubah menjadi data
B. Detail approve dapat dilihat pada gambar 5.19. PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 18Transaksi ubah data berhasil dilakukan
Gambar 5. 19 Detail monitoring telah diubah transaksi 2
5. Jika melihat history monitoring dari pelanggan tersebut akan diketahui
bahwa ada transaksi sebelumnya yang telah berhasil melakukan ubah data sebelum transaksi approve berhasil commit gambar 5.20. Jika melihat dari
detail approve, Petugas yang melakukan transaksi 1 akan menyadari bahwa data yang diapprove telah berubah gambar 5.21.
Gambar 5. 20Data history monitoring yang menjadi tidak konsisten
Gambar 5. 21 Detail approve transaksi 1 telah berubah, idmon versi sebelum
seharusnya 161029-124151-10899-MON PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
5.2.1.2. Pengujian Terhadap Proses Batalkan Status Monitoring dan Proses
Approve Data Pelanggan kWh 0 A.
Dengan Manajemen Transaksi 2PL
Proses ujicoba pada bagian ini pada umumnya sama seperti bagian sebelumnya, masalah concurrency control yang ingin dijawab dalam simulasi ini adalah
pencegahan lost of update jika 2 buah transaksi berjalan bersamaan dengan mengakses data yang sama. Berikut ini pada gambar 2.22 akan ditunjukan
diagram skenario pengujian ini.
Gambar 5. 22Diagram simulasi percobaan 2
Transaksi 1 adalah proses membatalkan status monitoring dan transaksi 2 adalah proses approve data monitoring. Seperti sudah dijelaskan sebelumnya, untuk
melakukan approve data, seorang pelanggan harus memenuhi syarat bahwa data monitoringnya harus berstatus sudah monitor. Jika pembatalan pada data
pelanggan tersebut lebih dulu dilakukan maka data pelanggan tidak lagi memiliki status monitoring. Itu artinya proses approve tidak dapat dilakukan. Jika
sebaliknya terjadi, proses approve mendahului mendapatkan lock lebih dulu proses pembatalan status monitoring maka data tidak dapat dibatalkan oleh
transaksi 1. Gambar 5.23 akan menunjukan gambar dari data pelanggan yang akan digunakan dalam uji coba kali ini. Idpel 225000060981 memiliki status sudah
dimonitor, oleh transaksi 1 datanya akan dibatalkan untuk dimonitoring kembali gambar 5.24. Sedangkan transaksi 2 pada gambar 5.25 akan melakukan approve
terhadap data ini. Transaksi 1 berhasil melakukan lock terhadap data pelanggan tersebut, transaksi 2 harus menunggu hingga transaksi 1 melepaskan locknya.
Prosedur batal_monitor_pasca
pada transaksi
1 menerapkan
DBMS_LOCK.SLEEP selama 30 detik. Hal ini berarti transaksi 2 yang dijalankan setelahnya akan bertabrakan dengan transaksi 1. Hasil dari transaksi 1 dapat
dilihat pada gambar 5.26 dimana pembatalan status monitoring berhasil dilakukan, data pelanggan tersebut tidak memiliki status monitoring lagi.
Transaksi 2 pada gambar 5.27 mengalami kegagalan sehingga harus rollback karena status monitoring pada data pelanggan menjadi null karena transaksi 1,
sehingga data tidak dapat diapprove. Gambar 5.28 menunjukan daftar pelanggan belum cek dimana data pelanggan tersebut berada dalam daftar belum cek karena
status monitoringnya yang null. PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 23 Daftar pelanggan kwh 0 belum approve
Gambar 5. 24 Halaman detail approve pelanggan pada transaksi 1
Gambar 5. 25 Transaksi 2 yang akan approve data pelanggan diatas
Gambar 5. 26 Transaksi 1 berhasil dilakukan, status monitoring pelanggan
menjadi null PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 27Transaksi 2 gagal dilakukan sehingga harus rollback
Gambar 5. 28 Data pelanggan 225000060981 berstatus belum monitoring
Proses lain yang menerapkan proses seperti dijelaskan diatas adalah proses batalkan status approve yang jika dijalankan tidak dapat membuat transaksi lain
berjalan bersamaan dengannya seperti approve data. Untuk proses upload data yang berjalan bersamaan atau upload data yang berjalan bersamaan dengan ubah
data, mekanisme yang terjadi adalah transaksi upload dan ubah yang lebih dulu melakukan locking akan disimpan datanya terlebih dahulu, baru setelah itu proses
lain yang mengikutinya. Untuk mekanisme 2 transaksi yang melakukan approve data yang sama secara bersamaan, transaksi yang lebih dahulu mendapatkan lock
akan mendapatkan hak untuk melakukan approve, transaksi yang mengikuti selanjutnya tidak dapat melakukan approve tersebut.
Tabel 5.1 dan 5.2 merupakan tabel pengujian yang menggambarkan proses terjadinya protokol 2PL yang dijalankan pada saat transaksi 1 dan transaksi
2 berjalan. Tabel 5.3 dan 5.4 merupakan tabel pengujian yang menggambarkan proses terjadinya transaksi 1 dan 2 tanpa protokol 2PL.
B. Tanpa Manajemen Transaksi 2PL
Jika sebelumnya telah dilakukan simulasi untuk menangani masalah lost of update dengan menggunakan method 2 phase locking, maka pada simulasi ini Penulis
menunjukan kasus transaksi 1 membatalkan status monitoring yang akan disela dengan transaksi 2 yang akan melakukan approve data yang sama. Tanpa adanya
2PL maka batalkan status monitoring yang disela dengan proses approve akan menyebabkan data mendapatkan idmon approve terlebih dahulu, sedangkan
setelah itu data baru bisa dibatalkan sehingga status approve bernilai YES dan status monitornya bernilai null.Hal ini akan menyebabkan data menjadi tidak
konsisten. 1.
Transaksi 1 akan melakukan pembatalan status monitoring pada gambar 5.29. Transaksi 2 akan melakukan approve data yang sama gambar 5.30.
Transaksi 1 akan diberikan delay selama 20 detik gambar 5.31 PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Gambar 5. 29 Transaksi 1 yang akan melakukan pembatalan monitoring
Gambar 5. 30 Transaksi 2 yang akan melakukan approve monitoring
Gambar 5. 31 kutipan stored procedure batal_monitor_pasca dimana delay diset
20 detik, klausa FOR UPDATE OF ditutup PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
2. Karena terjadidelay, transaksi 1 tidak dapat langsung mengubah status
monitor menjadi null. Pada saat yang bersamaan transaksi 2 berhasil melakukan approve sehingga membuat status approve bernilai YES
gambar 5.32. Setelah delay berakhir, data tetap dapat dibatalkan gambar 5.33. Berdasarkan aturan monitoring, data pelanggan tidak dapat
diapprove jika status monitornya bernilai null maupun sebaliknya. Disinilah terjadinya data yang tidak konsisten yang ditunjukan pada
gambar 5.34, 5.35, dan 5.36.
Gambar 5. 32 Transaksi 2berhasil dilakukan, status approve bernilai null
Gambar 5. 33 Transaksi 1 berhasil, karena status approve yang dibaca sebelum
delay adalah null maka data ini dapat dibatalkan. Namun, pada kenyataanya setelagh data dibaca kembali status approve menjadi YES.
....
Gambar 5. 34Pada daftar pelanggan sudah approve, data pelanggan memiliki
status approve dengan tanda silang, ini terjadi karena syarat status monitor tidak sama dengan null tidak terpenuhi
Gambar 5. 35Pada data history monitoring pelanggan tersebut, referensi idmon
versi sebelum menjadi tidak konsisten. Ada 2 record yang memiliki versi sebelum yang sama.
Gambar 5. 36Status monitoring pelanggan dengan idpel 225000020504 untuk
blth 201401 adalah null sedangkan status approve adalah YES. PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
Tabel 5. 1 Proses yang terjadi saat approve data pelanggan dan ubah data pelanggan subbab 5.2.1
Waktu Transaksi 1
Transaksi 2 Status
approve Idmon
t1 select idmon, status_app into v_idmon,
v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for
update of idpel,blth; v_versi_sebelum:=v_idmon;
null 161020-154938-06829-REV
t2 v_idmon:=function_tambah_idapp_pascav_
idpel,v_blth; p_idmon:=v_idmon;
select idmon, status_mon into v_idmon, v_status_mon from dlpd_pascabayar where
idpel=v_idpel and blth=v_blth for update of idpel,blth;
null 161020-154938-06829-REV
t3 IF v_idmon is not null then
select keadaan_mcb,ket,tgl_mon,verifikasi,koordin
at,gambar into v_mcb,v_ket,v_tgl_mon,v_verifikasi,v_koord
inat,v_gambar from record_dlpd_pascabayar where
idmon=v_versi_sebelum; update dlpd_pascabayar set
status_app=YES, idmon=v_idmon where idpel=v_idpel and blth=v_blth;
WAIT YES
161030-223411-06829-APP
t4 if v_versi_sebelum is not null
then WAIT
YES
161030-223411-06829-APP
insert into record_dlpd_pascabayar idpel,blth,idmon,koordinat,tgl_mon,verifika
si,ket,keadaan_mcb,versi_sebelum,user_id,g ambar,tgl_app
values v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_
mon,v_verifikasi,v_ket,v_mcb,v_versi_sebel um,v_user,v_gambar,to_charSYSDATE,DD-
MON-YY;
t5 commit;
p_status:=1; v_idmon:=function_tambah_idmon_pascav
_idpel,v_blth; p_idmon:=v_idmon;
YES
161030-223411-06829-APP
t6 else
raise ex_no_data_found; YES
161030-223411-06829-APP
t7 rollback;
p_status:=0; YES
161030-223411-06829-APP
Tabel 5. 2Proses yang terjadi saat pembatalan status monitoring data pelanggan dan approve data pelanggan subbab 5.2.2
Waktu Transaksi 1
Transaksi 2 Status
monitoring Idmon
t1 select idmon, status_mon into v_idmon,
v_status_mon from dlpd_pascabayar where idpel=v_idpel and blth=v_blth for update of
idpel,blth; v_versi_sebelum:=v_idmon;
YES 161016-202942-60981-MON
t2 v_idmon:=function_tambah_idmon_pascav
_idpel,v_blth; p_idmon:=v_idmon;
select idmon, status_app into v_idmon, v_status_mon from dlpd_pascabayar
where idpel=v_idpel and blth=v_blth for update of idpel,blth;
YES 161016-202942-60981-MON
t3 IF v_idmon is not null then
select keadaan_mcb,tgl_mon,koordinat,user_id,ga
mbar into v_mcb,v_tgl_mon,v_koordinat, v_user_sebelum,v_gambar
from record_dlpd_pascabayar where idmon=v_versi_sebelum;
update dlpd_pascabayar set status_mon=null, idmon=v_idmon where
idpel=v_idpel and blth=v_blth; v_ket:=monitoring ini dibatalkan oleh:
||v_user|| tgl ||to_charSYSDATE,DD- MON-YY hh24:mi:ss;
WAIT null
161031-000721-60981-REV
t4 if v_versi_sebelum is not null
then insert into record_dlpd_pascabayar
idpel,blth,idmon,koordinat,tgl_mon,verifika si,ket,keadaan_mcb,versi_sebelum,user_id,g
ambar values
v_idpel,v_blth,v_idmon,v_koordinat,v_tgl_ mon,v_alasan,v_ket,v_mcb,v_versi_sebelum
,v_user_sebelum,v_gambar;
WAIT null
161031-000721-60981-REV
t5 commit;
p_status:=1; v_idmon:=function_tambah_idapp_pascav_
idpel,v_blth; p_idmon:=v_idmon;
null 161031-000721-60981-REV
t6 else
raise ex_no_data_found; null
161031-000721-60981-REV t7
rollback; p_status:=0;
null 161031-000721-60981-REV
Tabel 5. 3Proses yang terjadi saat approve data pelanggan dan ubah data pelanggan tanpa protokol 2PLsubbab 5.2.1
Waktu Transaksi 1
Transaksi 2 Status
monitor Status
approve Idmon
Versi_sebelum
t1 select idmon, status_app into
v_idmon, v_status_mon from dlpd_pascabayar
where idpel=v_idpel and blth=v_blth; YES
null
161029-124151- 10899-MON
t2 v_idmon:=function_tambah_idapp_pa
scav_idpel,v_blth; p_idmon:=v_idmon;
select idmon, status_mon into v_idmon, v_status_mon from dlpd_pascabayar
where idpel=v_idpel and blth=v_blth; v_idmon:=function_tambah_idmon_pas
cav_idpel,v_blth; p_idmon:=v_idmon;
YES null
161029-124151- 10899-MON
t3 delay
IF v_idmon is not null then select idmon into v_versi_sebelum from
dlpd_pascabayar where idpel=v_idpel and blth=v_blth;
p_versisebelum:=v_versi_sebelum; update dlpd_pascabayar set
status_mon=YES, idmon=v_idmon where idpel=v_idpel and blth=v_blth;
if v_versi_sebelum is not null then
insert into record_dlpd_pascabayar idpel,blth,idmon,koordinat,tgl_mon,ve
YES null
161113-014129- 10899-REV
161029-124151- 10899-MON
rifikasi,ket,keadaan_mcb,versi_sebelum ,user_id
values v_idpel,v_blth,v_idmon,v_koordinat,to
_charv_date,DD-MON- YY,v_verifikasi,v_ket,v_mcb,v_versi_se
belum,v_user;
t4 delay
commit YES
null
161113-014129- 10899-REV
161029-124151- 10899-MON
t5 select idmon into v_versi_sebelum
from dlpd_pascabayar where idpel=v_idpel and blth=v_blth;
IF v_idmon is not null then select
keadaan_mcb,ket,tgl_mon,verifikasi,k oordinat,gambar into
v_mcb,v_ket,v_tgl_mon,v_verifikasi,v _koordinat,v_gambar
from record_dlpd_pascabayar where idmon=v_versi_sebelum;
YES null
161113-014129- 10899-REV
161029-124151- 10899-MON
t6 update dlpd_pascabayar set
status_app=YES, idmon=v_idmon where idpel=v_idpel and blth=v_blth;
if v_versi_sebelum is not null then
insert into record_dlpd_pascabayar idpel,blth,idmon,koordinat,tgl_mon,v
erifikasi,ket,keadaan_mcb,versi_sebel
YES YES
161113-014126- 10899-APP
161113-014129- 10899-REV
Tabel 5. 4Proses yang terjadi saat batalkan status monitoring dan approve tanpa protokol 2PLsubbab 5.2.2
um,user_id values
v_idpel,v_blth,v_idmon,v_koordinat,t o_charv_date,DD-MON-
YY,v_verifikasi,v_ket,v_mcb,v_versi_s ebelum,v_user;
t7 commit
YES YES
161113-014126- 10899-APP
161113-014129- 10899-REV
Waktu Transaksi 1
Transaksi 2 Status
monitor Status
approve Idmon
Versi_sebelum
t1 select idmon, status_mon into
v_idmon, v_status_mon from dlpd_pascabayar where idpel=v_idpel
and blth=v_blth; v_idmon:=function_tambah_idmon_p
ascav_idpel,v_blth; p_idmon:=v_idmon;
YES null
161018-123225- 20504-MON
t2 delay
select idmon, status_app into v_idmon, v_status_mon from dlpd_pascabayar
where idpel=v_idpel and blth=v_blth; v_idmon:=function_tambah_idapp_pas
YES null
161018-123225- 20504-MON
cav_idpel,v_blth; p_idmon:=v_idmon;
t3 Delay
select idmon into v_versi_sebelum from dlpd_pascabayar where idpel=v_idpel
and blth=v_blth; IF v_idmon is not null then
select keadaan_mcb,ket,tgl_mon,verifikasi,ko
ordinat,gambar into v_mcb,v_ket,v_tgl_mon,v_verifikasi,v_k
oordinat,v_gambar from record_dlpd_pascabayar where
idmon=v_versi_sebelum;
YES null
161018-123225- 20504-MON
t4 Delay
update dlpd_pascabayar set status_app=YES, idmon=v_idmon
where idpel=v_idpel and blth=v_blth; if v_versi_sebelum is not null
then insert into record_dlpd_pascabayar
idpel,blth,idmon,koordinat,tgl_mon,ve rifikasi,ket,keadaan_mcb,versi_sebelum
,user_id values
v_idpel,v_blth,v_idmon,v_koordinat,to _charv_date,DD-MON-
YY,v_verifikasi,v_ket,v_mcb,v_versi_se
YES YES
161113-025514- 20504-APP
161018-123225- 20504-MON
belum,v_user; t5
Delay commit
YES YES
161113-025514- 20504-APP
161018-123225- 20504-MON
t6 IF v_idmon is not null then
select keadaan_mcb,tgl_mon,koordinat,user
_id,gambar into v_mcb,v_tgl_mon,v_koordinat,
v_user_sebelum,v_gambar from record_dlpd_pascabayar where
idmon=v_versi_sebelum;
YES YES
161018-123225- 20504-MON
t7 update dlpd_pascabayar set
status_mon=null, idmon=v_idmon where idpel=v_idpel and blth=v_blth;
v_ket:=monitoring ini dibatalkan oleh: ||v_user|| tgl
||to_charSYSDATE,DD-MON-YY hh24:mi:ss;
Null YES
161113-025510- 20504-REV
t8 if v_versi_sebelum is not null
then insert into record_dlpd_pascabayar
idpel,blth,idmon,koordinat,tgl_mon,v erifikasi,ket,keadaan_mcb,versi_sebel
um,user_id,gambar values
v_idpel,v_blth,v_idmon,v_koordinat,v
Null YES
161113-025510- 20504-REV
161018-123225- 20504-MON
Keterangan: Pada saat t6 idmon kembali ke versi 161018-123225-20504-MON disebabkan karena versi monitoring tersebut merupakan parameter input
yang dibaca sebelumnya pada saat t1. Ini menyebabkan versi monitor yang dibaca saat itu kembali ke saat t1 untuk transaksi 1.
_tgl_mon,v_alasan,v_ket,v_mcb,v_ver si_sebelum,v_user_sebelum,v_gamba
r;
t9 Commit
Null YES
161113-025510- 20504-REV
161018-123225- 20504-MON
5.2.2. Pengujian Kasus The Uncommitted Dependency Problem
Skenario untuk pembuktian kasus The Uncommitted Dependency Problem dalam proses monitoring ini adalah ketika terdapat transaksi 1 yang sedang
melakukan proses monitoring dengan mengubah status monitor dari null menjadi YES dan pada saat yang hampir bersamaan terdapat transaksi 2 yang telah
membaca status monitor YES sehingga akan melakukan proses approve atau proses lainnya seperti membatalkan status monitor tersebut. Namun, oleh
transaksi 1 proses update ini belum commit sehingga ketika terjadi failure misalnya basis data dalam keadaan down atau listrik tiba-tiba mati maka
setelahnya basis data akan melaksanakan proses rollback pada transaksi 1, sehingga status monitor menjadi null. Oleh transaksi 2 perubahan ini tidak
dirasakan karena diawal status monitor yang dibacanya adalah YES. Setelah transaksi 2 akan melakukan proses approve dengan mengubah status approve
menjadi YES, maka sistem tidak dapat memperkenankan proses tersebut, karena status monitor data tersebut bernilai null yang artinya data belum dimonitor dan
tidak bisa diapprove. Skenario yang disebutkan diatas ditunjukan dalam tabel 5.5.
Tabel 5. 5Tabel skenario masalah the Uncommitted Dependency Problem Waktu
Transaksi 1 Transaksi 2
Status monitor
Status approve
t1 begin_transaction
Null null
t3 read status_monitor
Null null
t4 status_monitor=yes
begin_transaction Null
null t5
write status_monitor read status_monitor
Yes null
t6 rollbackcommit
read status_approve Null
null t7
status_approve=yes Null
null t8
write status_approve
Null null
t9 commit
Null null
Dalam kasus ini, proses pembuktian pemecahan masalah tersebut tidak dapat dilakukan karena skenario ini mungkin tidak akan terjadi pada proses
monitoring. Karena meskipun skenario ini dijalankan, sebelum transaksi 1 berhasil melakukan commit terhadap perubahan status monitor tersebut, maka
transaksi 2 yang berjalan setelahnya lihat tabel 5.5 pada waktu menunjukan t5 yang seharusnya membaca status monitor menjadi YES tidak dapat
melakukannya. Ini disebabkan karena dalam Oracle DBMS yang digunakan dalam sistem ini terdapat mekanisme proses write datasecara permanenpada
tabel tidak bisa dilakukan sebelum proses commit. Artinya agar transaksi 2 bisa membaca status monitor adalah YES, transaksi 1 harus commit terlebih dahulu.
Dalam Oracle status monitor untuk data dalam kasus ini akan tetap dalam keadaan null karena commit belum dilaksanakan, ini menyebabkan transaksi 2 juga akan
membaca status monitor tersebut dalam keadaan null.
5.2.3. Pengujian Kasus The Inconsistent Analysis Problem
Pengujian untuk The Inconsistent Analysis Problem tidak ditemukan Penulis dalam proses monitoring ini. Masalah inconsistent analysis problem ini terjadi
ketika sebuah transaksi membaca beberapa nilai dari basis data akan tetapi transaksi kedua mengubah beberapa nilai tersebut ketika eksekusi transaksi
pertama masih belum selelsai. Tidak ada masalah berkaitan alur proses monitor yang ditemukan Penulis berkaitan masalah ini sehingga skenario untuk masalah
ini tidak dapat dibuat. PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI
5.3. Analisa Hasil Uji Coba Terhadap Pengguna