Gambar Layar pertama untuk pemecahan masalah Lost Update

Transkripsi

1 Gambar Layar pertama untuk pemecahan masalah Lost Update 140

2 141 Gambar Layar kedua untuk pemecahan masalah Lost Update Setelah transaksi pada T 1 dikirimkan dengan tanpa status commit, transaksi T 2 mengirimkan transaksi berupa sintaks select dan update terhadap tabel master pada record KY001 juga seperti pada T 1.

3 142 Gambar Layar ketiga untuk pemecahan masalah Lost Update Tanpa menggunakan teknik locking, maka perubahan terhadap data umur menjadi 17 pada T 1 akan hilang, karena T 2 mengubah umur menjadi 20 pada saat T 1 masih belum menyelesaikan transaksinya. Untuk mencegah masalah lost update terjadi, pertama kali T 1 meminta dan mendapatkan sebuah exclusive lock pada tabel master dan record KY001. Dengan demikian T 1 dapat membaca nilai dari umur, mengubah nilainya dengan 17, dan menuliskan nilai tersebut ke dalam database. Ketika T 2 mulai dijalankan, T 2 juga akan meminta sebuah exclusive lock pada tabel master dan record KY001. Karena exclusive lock untuk item tersebut sedang digunakan oleh T 1, maka permintaan ini tidak langsung disetujui. T 2 harus

4 143 menunggu sampai lock pada item tersebut yang digunakan oleh T 1 dilepaskan yang artinya T 2 harus menunggu sampai T 1 menyelesaikan semua operasinya. Pada saat menunggu tersebut, ada kemungkinan terjadi timeout. Hal ini tergantung pada lamanya periode timeout yang ditetapkan oleh server. Setelah T 1 mengirimkan sintaks commit, maka semua lock yang dipakai akan dilepaskan, sehingga T 2 dapat dieksekusi. Dengan demikian masalah lost update dapat diatasi. Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file dari schedule.txt dari pemecahan masalah Lost Update

5 Evaluasi Pencegahan Masalah Uncommitted Dependency Menggunakan 2PL Pada evaluasi ini, T 1 mengirimkan transaksi berupa sintaks select dan update terhadap tabel master pada record KY001. Dengan demikian, T 1 menggunakan exclusive lock pada tabel master dan record KY001. Gambar Layar pertama untuk pemecahan masalah Uncommitted Dependency

6 145 Gambar Layar kedua untuk pemecahan masalah Uncommitted Dependency Setelah transaksi pada T 1 dikirimkan dengan tanpa status commit, transaksi T 2 mengirimkan transaksi berupa sintaks select dan update terhadap tabel master pada record KY001 juga seperti pada T 1.

7 146 Gambar Layar ketiga untuk pemecahan masalah Uncommitted Dependency Tanpa menggunakan teknik locking, ketika T 1 masih belum commit, dan T 2 menampilkan data pada tabel master, maka T 2 akan menampilkan data umur KY001 adalah 17. Hal ini menjadi sebuah kesalahan karena ternyata T 1 kemudian mengalami rollback. Untuk mencegah masalah uncommitted dependency terjadi, pertama kali T 1 meminta dan mendapatkan sebuah exclusive lock pada tabel master dan record KY001. Dengan demikian T 1 dapat membaca dan mengubah nilainya menjadi 17, dan menuliskan nilai tersebut ke dalam database. Ketika rollback terjadi, semua perubahan pada transaksi T 1 akan mengalami undone sehingga nilai dari umur item KY001 akan kembali

8 147 seperti nilai awalnya yaitu 23. Ketika T 2 mulai dijalankan, T 2 juga akan meminta sebuah exclusive lock pada item tersebut. Karena exclusive lock untuk item tersebut sedang digunakan oleh T 1, maka permintaan ini tidak langsung disetujui. T 2 harus menunggu sampai lock pada item tersebut yang digunakan oleh T 1 dilepaskan dan permintaan akan disetujui setelah proses rollback pada transaksi T 1 selesai dikerjakan. Dengan demikian masalah uncommited dependency dapat diatasi. Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari pemecahan masalah Uncommitted Dependency

9 Evaluasi Pengujian Pemecahan Masalah Inconsistent Analysis Menggunakan 2PL Terdapat dua buah transaksi yang dikirim bersamaan oleh dua client, yaitu T 1 dan T 2. T 1 meminta akses menulis terhadap tabel master. Lock yang diminta adalah Exclusive lock. Transaksi dua meminta akses membaca terhadap tabel master juga. Lock yang diminta adalah shared lock. Dengan demikian, T 2 akan menunggu sampai transaksi T 1 selesai, dan semua lock yang dipegang oleh T 1 dilepaskan. Gambar Layar pertama untuk pemecahan masalah Inconsistent Analysis

10 Gambar Layar kedua untuk pemecahan masalah Inconsistent Analysis 149

11 150 Gambar Layar ketiga untuk pemecahan masalah Inconsistent Analysis Dalam pengujian ini, setelah T 1 mengirimkan sintaks commit ke server, hal itu berarti T 1 tersebut sudah selesai. Selanjutnya, semua lock yang digunakan oleh T 1 akan dilepaskan sehingga status operasi pada T 2 akan diubah menjadi execute dan query akan dikirimkan kepada recovery manager. Dengan demikian masalah inconsistent analysis dapat diatasi. Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini :

12 151 Gambar Layar isi file schedule.txt dari pemecahan masalah Inconsistent Analysis Evaluasi Pengujian Penjadwalan Transaksi pada Saat Backup Ketika concurrency control menerima adanya sinyal backup dari backup restore manager, concurrency control akan membuat semua transaksi yang ada harus menunggu sebelum concurrency control mengirimkan sinyal kepada backup restore manager bahwa proses backup dapat dimulai. Selama proses backup sedang berlangsung, semua operasi di dalam transaksi akan berstatus wait. Jika ada transaksi baru yang diterima selama proses backup sedang berlangsung, transaksi tersebut akan diterima dan diberi status wait. Jika concurrency control menerima sinyal backup selesai dari backup restore manager, concurrency control akan menjalankan kembali mekanisme penjadwalan operasi-operasi yang berstatus wait karena menunggu proses backup yang sedang berlangsung.

13 152 Kasus I penjadwalan pada saat backup Jika T 1 mengirim operasi select dan transaksi belum mengirim commit, kemudian datang sinyal backup, maka operasi delete yang datang setelah backup akan menunggu dan akan di eksekusi setelah proses backup selesai. Jika proses backup telah selesai, concurrency control menerima sinyal backup selesai dari backup restore manager, sehingga semua transaksi yang menunggu akan dijalankan kembali. Gambar Layar untuk kasus I penjadwalan pada saat Backup

14 153 Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari kasus I penjadwalan pada saat backup Kasus II penjadwalan pada saat backup Jika T 1 mengirim operasi select dan transaksi belum menerima commit kemudian T 2 mengirim operasi delete pada tabel yang sama, maka T 2 akan menunggu T 1 commit atau rollback. Selama menunggu, ada kemungkinan T 2 mengalami timeout sesuai dengan waktu timeout yang ditentukan di server. Apabila pada saat tersebut, concurrency control menerima sinyal backup dari backup restore manager, maka kedua transaksi akan menunggu sampai proses backup selesai. Proses timeout pada T 2 tidak akan terjadi walaupun T 2 telah menunggu selama lebih dari waktu timeout yang ditentukan di server. Hal ini disebabkan transaksi T 1 dan T 2 menunggu proses backup selesai. Jika proses backup telah selesai, semua transaksi yang menunggu akan dijalankan kembali. Jika proses backup telah selesai, transaksi T 2 kembali akan menunggu T 1 sampai T 1 melepaskan lock yang sedang dipakai.

15 Gambar Layar pertama untuk kasus II penjadwalan pada saat Backup 154

16 Gambar Layar kedua untuk kasus II penjadwalan pada saat Backup 155

17 156 Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari kasus II penjadwalan pada saat Backup Kasus III penjadwalan pada saat backup Jika T 1 mengirim operasi select dan commit sekaligus, hal ini berarti transaksi T 1 sudah selesai dan concurrency control mengirim sintaks commit kepada recovery manager. Pada saat yang bersamaan, concurrency control menerima sinyal backup dari backup restore manager. Karena ada transaksi yang telah berstatus commit dari client namun belum berstatus commit dari recovery manager, maka concurrency control akan menunggu

18 157 status commit dari recovery manager sebelum mengirim sinyal backup dapat dimulai kepada backup restore manager. Jika ada transaksi yang datang selama proses backup sedang berlangsung, transaksi tersebut akan diterima, diberi status wait, dan akan dijadwalkan setelah proses backup selesai. Gambar Layar pertama untuk kasus III penjadwalan pada saat Backup

19 158 Gambar Layar kedua untuk kasus III penjadwalan pada saat Backup Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari kasus III penjadwalan pada saat Backup

20 Evaluasi Pengujian Penjadwalan Transaksi pada Saat Restore Ketika concurrency control menerima adanya sinyal restore dari backup restore manager, concurrency control akan mengalami rollback sebelum concurrency control mengirimkan sinyal kepada backup restore manager bahwa proses restore dapat dimulai. Jika ada transaksi baru yang diterima selama proses restore sedang berlangsung, transaksi tersebut akan diterima dan diberi status wait. Jika concurrency control menerima sinyal restore selesai dari backup restore manager, concurrency control akan menjalankan kembali mekanisme penjadwalan operasi-operasi yang berstatus wait karena menunggu proses restore yang sedang berlangsung. Kasus I penjadwalan pada saat restore Transaksi T 1 mengirim operasi select dan T 2 mengirim operasi delete. Jika pada saat tersebut concurrency control menerima sinyal restore dari recovery manager, maka semua transaksi akan mengalami rollback baik operasi di dalam transaksi tersebut berstatus execute ataupun berstatus wait.

21 Gambar Layar pertama untuk kasus I penjadwalan pada saat Restore 160

22 161 Gambar Layar kedua untuk kasus I penjadwalan pada saat Restore Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari kasus I penjadwalan pada saat Restore

23 162 Kasus II penjadwalan pada saat restore Transaksi T 1 mengirim operasi select. Pada saat tersebut, concurrency control menerima sinyal restore yang dikirim oleh backup restore manager. Concurrency control akan melakukan rollback terhadap transaksi T 1. Jika ada transaksi yang datang selama proses restore sedang berlangsung, transaksi tersebut akan diterima, diberi status wait, dan akan dijadwalkan setelah proses restore selesai. Gambar Layar pertama untuk kasus II penjadwalan pada saat Restore

24 163 Gambar Layar kedua untuk kasus II penjadwalan pada saat Restore Hasil pengujian dapat dilihat pada isi file schedule.txt berikut ini : Gambar Layar isi file schedule.txt dari kasus II penjadwalan pada saat Restore

25 Hasil Evaluasi Setelah melakukan pengujian terhadap masalah-masalah yang diakibatkan oleh pengaksesan bersamaan oleh multi user yang ditangani oleh concurrency control, maka dapat diketahui bahwa komponen concurrency control ini telah memiliki kemampuan antara lain : Banyak client dapat terhubung ke server sehingga database dapat diakses oleh multi user pada saat bersamaan. Komponen concurrency control ini telah mempunyai kemampuan untuk menerima transaksi yang terdiri atas satu atau banyak operasi yang dikirimkan oleh banyak client ke server secara bersamaan. Komponen concurrency control ini telah dapat melakukan analisis sintaks yang dikirimkan oleh client untuk memastikan bahwa transaksi yang dikirimkan oleh client telah menggunakan sintaks yang valid. Proses parsing dilakukan terhadap transaksi untuk memisahkan sebuah transaksi ke dalam satu atau banyak operasi sehingga dari setiap operasi akan dapat diketahui tabel, kolom, dan record yang diminta untuk diakses sesuai kondisi query pada operasi. Sintaks yang diinput telah dapat mengikuti aturan-aturan sebagai berikut : Sintaks untuk SELECT adalah SELECT < select_list >

26 165 < select_list > ::= { * column_name } [,...n ] FROM table_name [ WHERE condition ] Sintaks untuk INSERT adalah INSERT INTO table_name VALUES [,...n] Sintaks untuk UPDATE adalah UPDATE table_name SET { column_name = { expression } } [,...n ] [ WHERE condition ] Sintaks untuk DELETE adalah DELETE FROM table_name [ WHERE condition ] Komponen ini telah dapat membedakan permintaan akses membaca atau menulis ke dalam database, menentukan jenis lock yang dibutuhkan, mengecek tabel dan record yang sedang diakses oleh transaksi lain beserta lock yang sedang digunakan untuk dibandingkan dengan lock yang diminta. Berikutnya status operasi akan dapat ditentukan. Jika operasi berstatus wait, concurrency control akan membuat operasi tersebut menunggu untuk mengakses tabel dan record yang sedang di-lock oleh transaksi lain. Jika operasi

27 166 berstatus allowed, concurrency control akan mengirim XML query kepada recovery manager. Komponen concurrency control telah menggunakan teknik timeout untuk menangani kemungkinan terjadinya deadlock. Periode waktu timeout dengan menggunakan satuan detik dapat diubah melalui aplikasi server. Jika terdapat sebuah operasi yang menunggu untuk mendapatkan sebuah lock telah mencapai waktu timeout, transaksi tersebut akan mengalami rollback dan restart dengan lama waktu menunggu lock yang dibutuhkan diubah menjadi nol kembali. Multi user telah dapat mengakses database secara bersamaan dengan mengirim query berupa select. Multi user juga telah dapat melakukan manipulasi terhadap data dengan mengirimkan query berupa insert, update, dan delete. Schedule yang dibuat telah dapat berupa serial schedule dan nonserial schedule. Semakin banyak client yang mengakses database pada tabel dan record yang sama pada saat bersamaan, waktu yang dibutuhkan bagi sebuah transaksi mendapat status commit akan semakin bertambah. Hal ini disebabkan karena tabel dan record yang diakses adalah sama, sehingga implementasi yang digunakan berupa serial schedule. Kecuali apabila akses yang diminta oleh transaksi tersebut berupa akses membaca saja. Jika banyak client mengakses bagian berbeda pada database, implementasi yang digunakan berupa nonserial schedule sehingga transaksi yang dikirimkan oleh banyak

28 167 client tersebut dapat dieksekusi bersamaan tanpa gangguan. Transaksi yang dikirimkan oleh client telah dapat dilakukan per operasi. Pengakhiran transaksi berupa sintaks commit tidak harus ditulis bersamaan dalam satu kali pengiriman transaksi. Hal ini memungkinkan client untuk mengirimkan operasi selanjutnya dalam satu transaksi dan memungkinkan client untuk memutuskan mengirim status commit ataupun rollback terhadap transaksi tersebut. Jika client belum mengirimkan status commit terhadap transaksi yang telah dikirimkan, maka semua lock yang dipegang oleh transaksi tersebut tidak akan pernah dilepas. Semua lock yang dipakai oleh transaksi tersebut tersebut baru akan dilepaskan ketika client mengirimkan status commit terhadap transaksi tersebut atau jika client mengirimkan status rollback ataupun jika rollback terjadi karena mekanisme timeout. Hal ini akan memperlambat jalannya proses eksekusi terhadap transaksi-transaksi lainnya apabila tabel dan record yang akan diakses adalah sama. Komponen concurrency control telah dapat menerima sintaks commit ataupun rollback yang dikirimkan oleh client. Jika client mengirimkan sintaks commit, concurrency control akan mengirimkan sintaks commit tersebut kepada recovery manager. Jika client mengirimkan sintaks rollback, concurrency control akan mengirimkan sintaks rollback tersebut kepada recovery manager sehingga recovery manager dapat melakukan proses undo terhadap

29 168 transaksi tersebut. Berikutnya concurrency control akan menghapus data transaksi tersebut dari KeyUsedList, ScheduleOperation, dan ScheduleTransaction. Komponen concurrency control telah dapat menerima sinyal commit dari recovery manager yang menandakan bahwa transaksi telah selesai dieksekusi dan ditulis ke dalam database sehingga komponen dapat melakukan penjadwalan ulang. Komponen concurrency control telah dapat menerima sinyal backup dari backup restore manager. Setelah menerima sinyal ini, komponen concurrency control akan membuat status semua operasi di dalam transaksi berstatus wait selama proses backup. Kemudian, concurrency control akan mengirim sinyal kepada backup restore manager bahwa proses backup dapat dimulai. Selama proses backup sedang berlangsung, concurrency control akan membuat status semua transaksi tetap berstatus wait. Jika ada transaksi baru yang diterima selama proses backup sedang berlangsung, transaksi tersebut akan diterima dan diberi status wait. Setelah proses backup selesai, backup restore manager akan mengirim sinyal kepada concurrency control bahwa proses backup telah selesai, sehingga concurrency control akan menjalankan kembali mekanisme penjadwalan transaksi. Komponen concurrency control telah dapat menerima sinyal restore dari backup restore manager. Setelah menerima sinyal ini, komponen concurrency control akan menghapus semua lock yang sedang

30 169 digunakan dan melakukan rollback terhadap semua transaksi yang sedang berjalan. Kemudian, concurrency control akan mengirim sinyal kepada backup restore manager bahwa proses restore dapat dimulai. Selama proses restore sedang berlangsung, concurrency control akan membuat status semua transaksi yang baru diterima menjadi wait. Setelah proses restore selesai, backup restore manager akan mengirim sinyal kepada concurrency control bahwa proses restore telah selesai, sehingga concurrency control akan menjalankan kembali mekanisme penjadwalan transaksi. Jika user menutup window client, concurrency control akan melakukan pengecekan terhadap transaksi terakhir yang dikirim oleh client tersebut. Jika transaksi terakhir yang dikirimkan telah berstatus commit, tidak ada masalah. Namun, jika transaksi terakhir belum berstatus commit, concurrency control akan melakukan rollback terhadap transaksi terakhir tersebut. Banyak user dapat terhubung sebagai client pada sebuah aplikasi client dengan menggunakan konsep multithreading. Jika user menutup window utama dari client, pengecekan status transaksi akan dilakukan pada semua client yang terhubung melalui aplikasi client tersebut. Selain kemampuan diatas, penelitian ini juga memiliki keterbatasan, yaitu komponen concurrency control ini belum meliputi pengaksesan table dengan menggunakan sintaks join, multiple database, maupun distributed database.