Analisa Hasil Uji Coba Terhadap Program

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