BAB V Analisa Hasil
5.1.2 Pengujian Aplikasi Dengan Menggunakan Teknologi
5.1.2.1 Pengujian Terhadap Masalah Hilangnya Data
5.1.2.1.1 Pengujian Terhadap Proses Pemesanan
Berikut ini adalah ilustrasi pengujian yang dilakukan. Gambar 5.5 merupakan gambar user interface jumlah stok tiket awal pengujian aplikasi dengan menggunakan teknologi manajemen transaksi.
Gambar 5.5 User Interface Data Jumlah Stok tiket Awal Pengujian Terhadap Masalah Hilangnya Data Yang Diubah (The Lost Update Problem) Dengan
Menggunakan Teknologi Manajemen transaksi
Dalam pengujian ini, digunakan salah satu kelas dari kapal cirimai yaitu kelas II. Jumlah stok pesanan awal tiket = 3 dengan sisa tiket 85.
Berikut ini adalah simulasi aplikasi yang digunakan. Gambar 5.6 merupakan gambar user interface simulasi ada manajemen transaksi 1.
Gambar 5.6 User Interface Simulasi Ada Manajemen transaksi 1
Simulasi ini melakukan pemesanan tiket dengan jumlah pesanan sebanyak 1 tiket untuk kelas II dengan tujuan Tual. Pada simulasi ini, digunakan stored procedure yang diberikan delay yaitu dengan melakukan looping terhadap perintah update data stok. Berikut ini adalah perintah delay yang digunakan.
counter := 0; LOOP
counter := counter + 1;
EXIT WHEN counter = 10000000; END LOOP;
Berikut ini adalah stored procedure yang digunakan
Create or replace procedure simpanpesanan (
jumlah_dws IN pemesanan.jd%type, jumlah_ank IN pemesanan.ja%type, jumlah_by IN pemesanan.jb%type, total_hrg IN pemesanan.total%type, tiket IN pemesanan.kd_tiket%type, kapal IN pemesanan.kd_dkapal%type, kls IN pemesanan.kelas%type,
pesanerror out varchar2 ) as hasil integer; stokakhir integer; kap det_kapal.kapasitas%type; jumlahstok det_tiket.stok%type; counter integer ; counter1 integer ; BEGIN
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
update det_tiket set stok=stok where kd_tiket=tiket and kd_dkapal in (select kd_dkapal from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls and kelas.kd_kls=kls);
select stok into jumlahstok from det_tiket where kd_tiket=tiket and kd_dkapal =kapal;
counter := 0; LOOP
counter := counter + 1;
EXIT WHEN counter = 10000000; END LOOP;
stokakhir:=jumlahstok+( jumlah_dws+ jumlah_ank+ jumlah_by);
update det_tiket set stok=stokakhir where kd_tiket=tiket and kd_dkapal in (select kd_dkapal from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls and kelas.kd_kls=kls);
select kapasitas into kap from det_kapal where kd_dkapal=kapal; hasil:=(kap - stokakhir);
if(hasil<0) then rollback;
pesanerror:='Data Pesanan gagal'; else
insert into pemesanan(no_psn,user_id, jd, ja, jb, total, tgl,kd_tiket,kd_dkapal,jumlah,kelas) values(psn.nextval,user, jumlah_dws, jumlah_ank, jumlah_by, total_hrg, sysdate, tiket ,kapal,(jumlah_dws+ jumlah_ank+ jumlah_by),kls);
commit;
end if; -- akhiri perulangan pertama
exception
when others then rollback;
pesanerror:='Data digunakan transaksi Lain. Lakukan kembali Pemesanan'; end;
Gambar 5.7 merupakan gambar user interface simulasi ada manajemen transaksi 2.
Gambar 5.7 User Interface Simulasi Ada Manajemen transaksi 2
Simulasi ini melakukan pemesanan tiket dengan jumlah pesanan sebanyak 1 tiket untuk kelas II dengan Tujuan tual. Stored procedure yang digunakan pada simulasi ini juga diberikan delay. Stored procedure yang digunakan sama dengan stored procedure yang digunakan simulasi aplikasi yang pertama.
Gambar berikut ini akan menunjukan reaksi yang terjadi, jika kedua simulasi aplikasi yang menggunakan teknologi manajemen transaksi diatas saling bertabrakan.
Gambar 5.8 merupakan gambar user interface reaksi yang terjadi jika kedua simulasi aplikasi yang menggunakan teknologi manajemen transaksi dengan level isolasi serializable saling bertabrakan.
Gambar 5.8 User Interface Reaksi Yang Terjadi Jika 2 Simulasi Aplikasi Yang Menggunakan Teknologi Manajemen transaksi Dengan Level Isolasi Serializable
Saling Bertabrakan Pada Pengujian Masalah Hilangnya Data Yang Diubah ( The Lost Update Problem)
Gambar 5.9 merupakan gambar user interface data jumlah stok tiket yang dipengaruhi oleh simulasi aplikasi pertama.
Gambar 5.9 User Interface Data Jumlah Stok tiket Yang Dipengaruhi Simulasi Aplikasi Pertama Pada Pengujian Masalah Hilangnya Data Yang Diubah (The Lost Update Problem) Dengan Menggunakan Teknologi Manajemen transaksi
Dari gambar 5.8 diatas terlihat bahwa jika 2 simulasi aplikasi yang menggunakan teknologi manajemen transaksi dengan level isolasi serializable saling bertabrakan, maka salah satu simulasi aplikasi tersebut (simulasi aplikasi kedua) akan menggagalkan eksekusi terhadap dirinya. Hal ini dilakukan untuk menunggu simulasi aplikasi pertama selesai melakukan eksekusi (melakukan commit). Proses menunggu ini ditandai dengan keluarnya pesan yang memberikan informasi bahwa data digunakan oleh transaksi lain.
Sedangkan simulasi aplikasi pertama yang berhasil melakukan eksekusi, akan menambah jumlah stok tiket sebesar 1 unit. Sehingga jumlah stok tiket yang didapat menjadi 3+1 =4. Hal ini terlihat dari gambar 5.9 diatas.
Setelah simulasi aplikasi pertama berhasil melakukan eksekusi (commit) terhadap transaksinya. Maka simulasi aplikasi kedua yang menunggu tadi, dapat
melanjutkan eksekusi yang sempat tertunda dengan kembali melakukan pemesanan. Simulasi aplikasi kedua ini juga akan menambah jumlah stok tiket sebanyak 1 unit. Sehingga jumlah stok tiket akhir yang didapat menjadi 3+1+1 = 5. Gambar 5.10 akan menunjukan data akhir jumlah stok barang yang dipengaruhi kedua simulasi aplikasi.
Gambar 5.10 User Interface Data Akhir Jumlah Stok tiket Yang Dipengaruhi Kedua Simulasi Aplikasi Yang Menggunakan Teknologi Manajemen
transaksi Pada Pengujian Masalah Hilangnya Data Yang Diubah (The Lost Update Problem)
Dari user interface diatas, terlihat bahwa salah satu kelas yaitu kelas II pada tanggal 28 juni mempunyai jumlah stok akhir = 5. Pemesanan yang dilakukan masing-masing sebanyak 1 tiket pada 2 simulasi aplikasi.
Jumlah stok akhir sesuai dengan yang seharusnya yaitu 3+1+1 = 5. Dalam pengujian dengan menggunakan teknologi manajemen transaksi ini, terlihat tidak
terjadi masalah pada jumlah stok akhir tiket yang terpesan. Sehingga masalah hilangnya data yang diubah (the lost update problem), tidak terjadi.
Tabel 5.2 berikut merupakan tabel yang menggambarkan proses yang terjadi pada pengujian aplikasi yang menggunakan teknologi manajemen transaksi, terhadap masalah hilangnya data yang diubah (the lost update problem).
Waktu
Simulasi Aplikasi Ada Manajemen Transaksi
1
Simulasi Aplikasi Ada Manajemen Transaksi 2 Jumlah_Stok t1 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE update det_tiket set stok=stok
where kd_tiket=tiket and kd_dkapal in (select kd_dkapal from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls and kelas.kd_kls=kls); 3 t2
select stok from det_tiket where kd_tiket=520 and
kd_dkapal=18; 3 t3 stokakhir:=stok+( jumlah_dws+ jumlah_ank+ jumlah_by); = 3+1 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE update det_tiket set stok=stok
where kd_tiket=tiket and kd_dkapal in (select kd_dkapal
from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls
and kelas.kd_kls=kls);
3
t4 Delay
select stok from det_tiket where kd_tiket=520 and
kd_dkapal=18; sstok:=stok+( jumlah_dws+
jumlah_ank+ jumlah_by); 3 t5 update det_tiket set stok=
stokakhir where kd_tiket=520
Delay &
exception
and kd_dkapal in (select kd_dkapal from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls and kelas.kd_kls=C002); COMMIT;
when others then rollback; pesanerror:='Data digunakan. Lakukan kembali pemesanan’;
& Wait t6 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE select stok from det_tiket where
kd_tiket=520 and kd_dkapal=18; 4 t7 sstok:=stok+( jumlah_dws+ jumlah_ank+ jumlah_by); = 4+1 4 t8 Delay 4 t9
update det_tiket set stok= sstok where kd_tiket=520 and kd_dkapal in (select kd_dkapal
from det_kapal,kelas where kelas.kd_kls=det_kapal.kd_kls
and kelas.kd_kls=C002); COMMIT;
