Manajemen Transaksi(3)
Basisi Data: kesadaran akan hilangnya informasi ketika sistem komputer Anda tiba-tiba macet .
Pengendalian konkurensi (concurrency control) • Salah satu karakteristik dasar dari sebuah transaksi yang harus dipenuhi adalah Isolasi, yang menjamin tereksekusinya semua transaksi pada sebuah sistem yang konkuren dengan benar sehingga konsistensi basis data dapat tetap terpelihara. • Karena itu menjadi sangat penting untuk mengendalikan interaksi antara transaksi-transaksi yang sedang bersaing (konkuren), melalui sebuah mekanisme yang biasa disebut dengan mekanisme Pengendalian Konkurensi (concurrency ( concurrency control ). ). • Mekanisme ini didasarkan pada prinsip-prinsip serializability
Pengendalian konkurensi (concurrency control) • Salah satu karakteristik dasar dari sebuah transaksi yang harus dipenuhi adalah Isolasi, yang menjamin tereksekusinya semua transaksi pada sebuah sistem yang konkuren dengan benar sehingga konsistensi basis data dapat tetap terpelihara. • Karena itu menjadi sangat penting untuk mengendalikan interaksi antara transaksi-transaksi yang sedang bersaing (konkuren), melalui sebuah mekanisme yang biasa disebut dengan mekanisme Pengendalian Konkurensi (concurrency ( concurrency control ). ). • Mekanisme ini didasarkan pada prinsip-prinsip serializability
Lock-Based Protocol(1) • Salah satu cara untuk menjamin serializability adalah dengan mensyaratkan bahwa akses ke satuan-satuan data harus dilakukan dengan menerapkan eksklusivitas. Artinya, selama sebuah transaksi sedang mengakses sebuah satuan data, maka tidak ada transaksi lain yang boleh melakukan perubahan terhadap satuan data tersebut. • Metode yang umum digunakan untuk menerpakan hal ini adalah dengan kewajiban melakukan penguncian pada suatu satuan data sebelum ia ingin diakses.
Lock-Based Protocol(2) • Ada dua jenis (mode) penguncian dasar yang digunakan dalam mekanisme ini, yaitu: – Bersama (shared ). Jika sebuah transaksi Ti dapat melakukan penguncian dengan mode ini (dilambangkan dengan S) terhadap satuan data Q, maka Ti dapat membaca, tetapi tidak dapat mengubah nilai Q tersebut – Tunggal (exclusive). Jika sebuah transaksi Ti, dapat melakukan penguncian dengan mode ini (dilambangkan dengan X) terhadap satuan data Q, maka Ti dapat membaca maupun mengubah nilai Q tersebut.
Lock-Based Protocol(3) • Pada mekanisme ini ditetapkan bahwa penguncian dengan mode shared atau S untuk satuan data Q dapat diberikan kepada sebuah transaksi, jika satuan data tersebut sedang tidak dikunci oleh transaksi yang lain, atau paling tidak ia sedang dikunci dengan mode shared juga oleh transaksi lainnya. • Jika satuan data tersebut sedang dikunci dengan mode exclusive, maka hak penguncian kepada transaksi tersebut tidak dapat diberikan (ditunda pemberiannya).
Lock-Based Protocol(4) • Jika mode penguncian yang diinginkan oleh sebuah transaksi adalah exclusive atau X, maka hak penguncian dengan mode ini hanya akan diberikan oleh modul concurrency control, jika satuan data tersebut tidak sedang dikunci dengan mode apapun. • Tabel ini mencerminkan aturan penguncian, yaitu:
S X
S true false
X false false
Lock-Based Protocol(5) • Sebuah transaksi dapat meminta penguncian bahwa mode shared terhadap satuan data Q dengan menjalankan perintah lock-S(Q) dan dengan mode exclusive dengan menjalankan perintah lock-X(Q). • Setelah sebuah transaksi berhasil mendapatkan hak penguncian terhadap suatu satuan data dan kemudian selesai melakukan pengaksesan terhadap satuan data tersebut, maka ia harus segera mungkin melepaskan pengunciannya, agar transaksi lain yang mungkin juga ingin mengakses satuan data yang sama pada saat yang hampir bersamaan tidak lama menunggu untuk mendapatkan hak penguncian. • Perintah untuk melepaskan hak penguncian adalah unlock(Q)
Lock-Based Protocol(6) • Dua buah transaksi T1 dan T2. T1 berfungsi untuk melakukan pentransferan dana dari rekening B ke rekening A sebesar Rp. 100.000,• T1: lock-x (B) read (B) B := B – 100 000 write (B) unlock (B) lock-x (A) read (A) A := A + 100 000 write (A) unlock (A)
Lock-Based Protocol(7) • Sementara transaksi T2 yang hanya berfungsi untuk menampilkan total saldo dari kedua rekening, A dan B: • T2: lock-s (A) read (A) unlock (A) lock-s (B) read (B) write (B) unlock (B) display (A + B)
Lock-Based Protocol(8) • Anggaplah saldo awal dari rekening A dan B masing-masing adalah Rp. 1.000.000,- dan Rp. 2.000.000,-. • Jika kedua transaksi dieksekusi secara serial, baik dengan urutan maupun , maka transaksi T2 akan menampilkan nilai Rp. 3.000.000,• Jika kemudian kedua transaksi dieksekusi secara konkuren dengan schedule di bawah ini, maka transaksi T2 akan menampilkan nilai Rp. 2.900.000,- yang tentu saja tidak benar. • Hal ini terjadi karena transaksi T1 melepaskan penguncian terhadap satuan data B terlalu cepat, yang kemudian dibaca oleh transaksi T2 secara tidak konsisten
Lock-Based Protocol(9) T1
T2
lock-x (B) read (B) B := B – 100 000 write (B) unlock (B)
lock-s (A)
lock-x (A) read (A) A := A + 100 000 write (A) unlock (A)
read (A) unlock (A) lock-s (B) read (B) write (B) unlock (B) display (A + B))
Lock-Based Protocol(10) • Karena schedule konkuren tersebut menghasilkan informasi yang tidak akurat, maka katakanlah kita melakukan perubahan pada letak perintah pelepasan penguncian (unlock) dengan menundanya hingga akhir transaksi, menjadi transaksi T3 dan T4 sebagai berikut: • T3: lock-x (B) read (B) B := B – 100 000 write (B) lock-x (A) read (A) A := A + 100 000 write (A) unlock (B) unlock (A)
Lock-Based Protocol(11) • T4: lock-s (A) read (A) lock-s (B) read (B) write (B) unlock (A) unlock (B) display (A + B)
Selanjutnya jika kedua transaksi tersebut dieksekusi secara konkuren, dengan potongan schedule sebagai beriut:
Lock-Based Protocol(12) T3
T4
lock-x (B) read (B) B := B – 100 000 write (B)
lock-s (A) lock-x (A)
read (A) lock-s (B)
Lock-Based Protocol(13)
• Secara teoritis, Schedule ini memberikan hasil yang akurat sesuai dengan hasil yang diberikan oleh schedule serial. Akan tetapi, secara praktis, schedule tersebut tidak dapat dilaksanakan dengan tuntas, karena mengalami kondisi d e a d l o c k . • Kondisi ini terjadi ketika kedua transaksi berada dalam keadaan saling menunggu, sehingga kedua transaksi tidak akan pernah selesai dieksekusi. • Jika kita perhatikan transaksi T3, perintah lock-X(B) akan membuat satuan data B dikunci secara exclusive oleh transaksi tersebut. • Sementara itu, transaksi T4 mengawali aksi-aksinya dengan melakukan penguncian terhadap satuan data A. • Ketika transaksi T3 telah menjalankan operasi write(B) dan kemudian menjalankan perintah lock-X(A), penguncian satuan data A secara exclusive menjadi tertunda (yang juga menunda aksi-aksi berikutnya dalam transaksi T3, karena satuan data A tersebut sedang dikunci oleh transaksi T4.
Lock-Based Protocol(14) • Sementara itu, transaksi T4 yang telah menjalankan operasi read(A) dan bersiap melakukan penguncian terhadap satuan data B dengan perintah lock-S(B) juga tidak dapat diteruskan, karena pada saat yang sama satuan data tersebut telah dikunci oleh transaksi T3. • Kondisi yang saling menunggu inilah yang biasa dikenal dengan istilah d e a d l o c k yang tidak dapat diatasi dengan baik oleh DBMS.
Lock-Based Protocol(15) • Jika operasi-operasi dari beberapa transaksi dilakukan dilakukan tanpa penerapan penguncian atau jika pelepasan penguncian dilakukan terlalu cepat, kita akan dapat mengalami ketidakakuratan/ketidakk ketidakakuratan/ketidakkonsistenan onsistenan informasi. • Sementara jika aksi pelepasan penguncian dilakukan di akhir transaksi, maka kondisi deadlock akan akan mudah terjadi. • Ini merupakan keadaan dilematis yang memang biasa dihadapi dalam sebuah sistem konkuren yang memanfaatkan mekanisme penguncian (locking (locking )
Lock-Based Protocol(16) • Kita akan menetapkan bahwa setiap transaksi yang terlibat dalam sebuah sistem harus mengikuti sekumpulan aturan yang disebut Aturan Penguncian (locking ( locking protocol ), ), yang menunjukkan kapan sebuah transaksi boleh dikunci dan kapan melepaskan penguncian terhadap setiap satuan data • Locking protocol protoco l kelak akan dapat menentukan scheduleschedule mana schedule mana saja yang boleh dipilih • Pada dasarnya mekanisme locking protocol ini hanya akan membolehkan schedule-schedule yang schedule-schedule yang bersifat conflictserializable. serializable .
Pemberian Locking(1) • Ketika sebuah transaksi meminta penguncian pada sebuah satuan data dengan mode tertentu (A), dan saat itu tidak ada transaksi t ransaksi lainnya yang melakukan penguncian terhadap satuan data yang sama dalam mode yang memiliki konflik dengan mode A, maka penguncian tersebut dapat diberikan. Akan tetapi, harus pula dicermati terjadinya kondisi berikut ini. transaksi T1 mendapatkan hak penguncian • Anggaplah sebuah transaksi dengan mode shared terhadap sebuah satuan data, dan pada saat yang sama transaksi lainnya T2 menginginkan penguncian dengan mode exclusive terhadap satuan data yang sama. Jelas sekali, T2 harus menunggu hingga T1 melepaskan pengunciannya. • Sementara itu, sebuah transaksi lain T3 juga menginginkan penguncian dengan mode shared terhadap satuan data yang sama. • Karena mode ini kompatibel (cocok) dengan mode penguncian yang diterapkan oleh transaksi T1, maka kepada T3 dapat segera diberikan kesempatan untuk juga melakukan penguncian dengan mode tersebut.
Pemberian Locking(2) • Pada selang waktu tertentu transaksi T1 melepaskan pengunciannya, akan tetapi datang lagi transaksi lainnya, katakanlah T4, yang juga ingin melakukan penguncian dengan mode shared di saat T3 masih belum melepaskan pengunciannya. Sehingga kemudian T4 dibolehkan untuk melakukan penguncian.
• Hal ini dapat berlangsung terus, tetapi akan mengakibatkan transaksi T2 yang sedari awal dalam kondisi menunggu melakukan penguncian tetap tidak dapat mendapatkan hak untuk melakukan penguncian terhadap satuan data tersebut. Jadi, tidak ada kemajuan bagi transaksi T2. kondisi ini disebut starvasion.
Pemberian Locking(3) • Untuk menghindari kondisi s t a r v a s i o n ini, maka ketika sebuah transaksi Ti menginginkan penguncian terhadap satuan data Q dalam mode tertentu (misalnya mode A), maka hak penguncian tersebut baru akan diberikan apabila: – Tidak ada transaksi lain yang sedang melakukan penguncian terhadap satuan data Q dengan mode yang memiliki konflik dengan mode A – Tidak ada transaksi lain yang sedang menunggu untuk mendapatkan penguncian terhadap satuan data Q yang telah lebih dahulu mengajukan permintaan penguncian tersebut.
Locking Protokol Dua Fase(1) • Protokol ini menginginkan bahwa setiap transaksi yang akan menjalankan penguncian dan melepaskan penguncian harus melalui 2 fase atau tahapan, yaitu: – Fase pertumbuhan (Growing Phase). Sebuah transaksi dapat melakukan sejumlah penguncian, tetapi belum melepaskan satu pun pengunciannya – Fase pelepasan (Shrinking Phase). Sebuah transaksi dapat melepaskan sejumlah penguncian, tetapi belum melakukan penguncian yang baru
awalnya, sebuah transaksi akan berada dalam fase pertumbuhan. Transaksi tersebut akan melakukan penguncian sebanyak yang dibutuhkan nya. • Ketika transaksi mulai melepaskan sebuah penguncian, ia mulai memasuki fase pelepasan, tanpa ada permintaan penguncian berikutnya •
Pada
Locking Protokol Dua Fase(2) • Sebagai contoh, transaksi T3 dan T4 di pembahasan sebelumnya merupakan transaksi dua fase. Dilain pihak, transaksi T1 dan T2 bukanlah transaksi dua fase. • Ingat bahwa instruksi unlock tidak perlu muncul di akhir transaksi. Dalam kasus transaksi T3, kita dapat memindahkan instruksi unlock(B) persis setelah instruksi lock-X(A), dan tetap berada dalam kondisi penguncian dua fase. • Locking protokol dua fase menjamin adanya conflict serializability • Titik dalam schedule dimana transaksi tersebut telah mendapatkan penguncian akhir (di akhir fase pertumbuhan) disebut titik penguncian (lock point) transaksi. Sekarang, transaksi-transaksi dapat diurutkan berdasarkan titik penguncian mereka. Penguncian ini, secara nyata, menunjukkan sifat serializability dalam pengeksekusian seluruh transaksi.
Locking Protokol Dua Fase(3) • Locking protokol dua fase tidak dapat menjamin tidak terjadinya kondisi deadlock . • Dapat dilihat bahwa transaksi T3 dan T4 merupakan transaksi dua fase, tetapi seperti yang terlihat pada schedule 2, ternyata juga mengalami kondisi deadlock . • Terdapat beberapa varian dari mekanisme locking protocol dua fase ini: – Locking protocol dua fase yang ketat (strict two-phase locking protocol ). Dengan mekanisme ini, juga dikehendaki bahwa semua penguncian dengan mode exclusive dari sebuah transaksi harus tetap dipegang hingga transaksi berada dalam status Berhasil sempurna (Commited). Setiap data yang ditulis oleh transaksi yang belum berstatus commited terus dikunci dalam mode exclusive, untuk mencegah transaksi lainnya melakukan pembacaan terhadap satuan data tersebut. – Locking protocol dua fase yang padat (rigorous two-phase locking protocol ), yang menghendaki semua penguncian (baik yang mode exclusive maupun shared) tetap diterapkan hingga transaksi berstatus berhasil sempurna (commited). Mudah diperksa, bahwa dengan mekanisme ini, transaksi-transaksi dapat dikerjakan secara serial sesuai
Locking Protokol Dua Fase(4) • Pertimbangkan kedua transaksi berikut ini yang hanya menampilkan operasi read dan write yang relevan. • T5: read (a1) read (a2) ……. read (an) write (a1)
• T6: read (a1) read (a2) write (a1 + a2)
Locking Protokol Dua Fase(5) • Jika kita menerapkan locking protocol dua fase, maka T5 harus mengunci a1 dalam mode exclusive. Karena itu, semua eksekusi konkuren dari kedua transaksi akan menjadi eksekusi serial. • Akan tetapi, T5 sebenarnya hanya membutuhkan penguncian dengan mode exclusive di akhir transaksi di saat penulisan a1 akan dilakukan. • Karena itu, jika pada awalnya T5 menerapkan mode shared dalam pengunciannya, dan kemudian menjelang akhir transaksi mode tersebut diubah menjadi exclusive, kita akan mendapatkan kondisi konkurensi yang lebih baik, karena T5 dan T6 dapat mengakses a1 dan a2 secara simultan
Locking Protokol Dua Fase(6) • Pengamatan ini membawa kita pada upaya perbaikan dari mekanisme Locking protocol dua fase, dimana upaya konversi mode penguncian dimungkinkan. • Kita akan menerapkan langkah peningkatan mode penguncian dari shared menjadi exclusive, dan penurunan mode penguncian dari exclusive menjadi shared. • Operasi untuk peningkatan mode tersebut disebut u p g r a d e dan operasi sebaliknya sebagai d o w n g r a d e . • Peningkatan mode ini hanya akan berlaku pada fase pertumbuhan, sementara penurunan mode akan berlaku pada fase pelepasan.
Locking Protokol Dua Fase(7) • Contoh, transaksi T5 dan T6 dapat dieksekusi secara konkuren dengan mekanisme locking protocol dua fase yang telah diperbaiki, sebagaimana yang ditunjukkan pada schedule yang tidak lengkap berikut ini: T5
T6
lock-s (a1) lock-s (a1) lock-s (a2) lock-s (a2) lock-s (a3) lock-s (a4) unlock (a1) unlock (a2) lock-s (an) upgrade (a1)
Timestamp-Based Protocol • Dalam mekanisme locking protocol yang telah dibahas sebelumnya, urutan diantara setiap pasang transaksi yang memiliki konflik ditentukan pada saat eksekusi oleh penguncian pertama yang diminta kedua transaksi dengan mode yang tidak kompatibel • Metode yang lain yang dapat digunakan untuk menentukan urutan serializability adalah dengan memilih urutan transaksi sebelumnya. • Metode yang paling populer untuk itu adalah skema timestamp-ordering .
Timestamp (1) • Skema ini menjamin serializability dengan memilih sebuah urutan di antara setiap pasangan transaksi. Untuk setiap transaksi Ti di dalam sistem, ditetapkan sebuah nilai berdasarkan waktu (semacam tera waktu atau timestamp) yang tetap dan unik dengan notasi TS(Ti). • Timestamp ini ditentukan oleh DBMS sebelum transaksi Ti mulai dikerjakan. • Jika sebuah transaksi Ti telah diberi timestamp TS(Ti) dan kemudian datang transaksi baru Tj, maka TS(Ti) < TS(Tj).
Timestamp (2) • Ada dua metode sederhana untuk menerapkan skema ini: – Memanfaatkan jam komputer (system lock ) sebagai timestamp, sehingga timestamp transaksi akan sama dengan nilai yang ditunjukkan jam komputer ketika transaksi tersebut memasuki sistem – Memanfaatkan sebuah penghitungan lojik (logical counter ) yang terus bertambah nilainya begitu nilai terakhir (current value)-nya diberikan pada sebuah transaksi baru, sehingga timestamp transaksi akan sama dengan nilai penghitungan(counter ) di saat transaksi tersebut memasuki sistem
Timestamp (3) • Timestamp-timestamp transaksi tadi akan menentukan urutan dari serializability -nya. Karena itu, jika timestamp transaksi Ti lebih kecil daripada timestamp transaksi Tj (TS(Ti) < TS(Tj)), maka skema ini menjamin bahwa schedule yang dihasilkan sama dengan schedule serial dimana transaksi Ti selalu dilaksanakan sebelum transaksi Tj. • Untuk menerapkan skema ini, kita menerapkan dua nilai timestamp pada setiap satuan data Q: – W-timestamp(Q) yang menunjukkan nilai timestamp terbesar dari setiap transaksi yang berhasil menjalankan operasi wite(Q) – R-timestamp(Q) yang menunjukkan nilai timestamp terbesar dari setiap transaksi yang berhasil menjalankan operasi read(Q).
• timestamp ini akan terus diperbaharui ketika ada perintah baru read(Q) atau write(Q) yang dieksekusi.
Timestamp-ordering Protocol (1) • Protokol Timestamp-ordering menjamin bahwa setiap operasi read dan write yang memiliki konflik dieksekusi sesuai urutan timestamp. • Protokol ini beroperasi mengikuti aturan berikut ini: – Untuk transaksi Ti yang menjalankan operasi read(Q) • Jika TS(Ti) < w-timestamp(Q), maka Ti perlu membaca kembali nilai Q yang telah ditulis. Karena itu, operasi read ini akan ditolak dan Ti akan dibatalkan (di rollback). • Jika TS(Ti) ≥ w-timstamp( Q), maka operasi read dieksekusi, dan R-timestamp(Q) diisi dengan nilai terbesar di antara TS(Ti) dan R -timestamp(Q)
– Untuk transaksi Ti yang menjalankan operasi write(Q) • Jika TS(Ti) < R-timestamp(Q), maka nilai Q yang baru dihasilkan Ti adalah nilai yang tidak akan dimanfaatkan lagi, dan sistem berasumsi bahwa nilai tersebut tidak pernah dihasilkan. Karena itu, operasi w r i t e ditolak dan transaksi Ti dibatalkan (di rollback) • Jika TS(Ti) < w-timestamp(Q), maka itu berarti TI sedang berusaha melakukan penulisan nilai Q yang kadaluarsa. Karena itu, operasi w r i t e ini akan ditolak dan Ti akan dibatalkan (di rollback) • Diluar kondisi a dan b di atas, operasi w r i t e dieksekusi, dan W-timestamo(Q) diberi nilai yang sama dengan TS(Ti).
Timestamp-ordering Protocol (2) • Terhadap transaksi Ti, yang dibatalkan (di-rollback ) oleh mekanisme concurrency-control di atas sebagai hasil dari penggunaan operasi read dan w r i t e , akan diberikan sebuah nilai timestamp yang baru dan diulang kembali • Untuk menggambarkan protokol ini, kita mempertibangkan transaksi T7 dan T8. Transaksi T7 menampilkan nilai saldo rekening A dan B dan didefinisikan sebagai: – T7:
read (B) read (A) display (A + B)
Timestamp-ordering Protocol (3) • Transaksi T8 yang mentransfer dari rekening A ke rekening B dan kemudian menampilkan isi keduanya: – T8:
read (B) B “= B – 100 000 write (B) read (A) A := A + 100 000 write (A) display (A + B)
Timestamp-ordering Protocol (4) • Dalam menentukan schedule dengan protokol timestamp, kita mengasumsikan bahwa sebuah transaksi diberikan sebuah timestamp dengan segera sebelum instruksi pertama. Karena itu, dalam schedule berikut ini, TS(T7) < TS(T8) dan schedule ini mungkin dieksekusi dengan menggunakan protokol timestamp-ordering. T7
T8
read (B) read (B) B := B - 100000 write (B) read (A) read (A) lock-s (A) A := A + 100000 write (A) display (A + B)
Timestamp-ordering Protocol (5) • Eksekusi awal dapat juga dihasilkan oleh locking protokol dua fase. Akan tetapi, ada schedule yang diperbolehkan dalam locking protokol dua fase tetapi tidak berlaku dalam timestamp protocol, dan sebaliknya • Protokol timestamp-ordering menjamin conflict serializability. • Pernyataan ini berasal dari fakta bahwa operasi-operasi yang memiliki konflik satu sama lain diproses dalam urutan timestamp-nya. • Dengan protokol ini, sistem konkuren terbebas dari kondisi deadlock, karena tidak ada transaksi yang harus menunggu.
Validation-based Protocol (1) • Dalam kasus dimana sebagian besar transaksi merupakan transaksi yang read-only (didominasi oleh instruksi pembacaan data), tingkat konflik di antara transaksitransaksi menjadi rendah. Karena itu, walaupun transaksitransaksi ini dieksekusi tanpa pengawasan skema concurrency control, konsistensi sistem tidak akan terpengaruh/terganggu. • Padahal, penerapan skema concurrency control, akan mengakibatkan bertambahnya proses/program yang harus dikerjakan dan berpeluang menunda pelaksanaan transaksi menjadi lebih lama • Karenanya, sangat logis untuk menggunakan skema alternatif lain yang waktu tambahan (overhead)-nya bisa lebih kecil, yakni dengan meminimalkanpenerapan skema concurrency control tersebut
Validation-based Protocol (2) • Dengan asumsi setiap transaksi Ti dieksekusi dalam dua atau tiga fase berbeda selama masih berlangsung pada apakah transaksi tersebut hanya melakukan pembacaan data atau melakukan perubahan data. • Ketiga fase tersebut adalah: – Fase pembacaan. Selama fase ini, eksekusi transaksi Ti akan dijalankan. Nilai dari berbagai satuan data dibaca dan kemudian disimpan ke dalam variabel-variabel lokal untuk Ti. Semua operasi write dilakukan terhadap variabel lokal temporer, tanpa perubahan ke basis data yang aktual – Fase validasi. Transaksi Ti membentuk uji validasi untuk menentukan apakah transaksi tersebut dapat melakukan penyalinan/pengubahan ke basis data dari variabel-variabel lokal temporer yang nilai-nilainya diperoleh dari operasi-operasi write tanpa menyebabkan pelanggaran serializability – Fase penulisan. Jika fase validasi untuk transaksi Ti dalam langkah kedua di atas berhasil, maka perubahan sesungguhnya dilakukan ke basis data. Jika fase validasi ini tidak berhasil, mka Ti akan dibatalkan (di rollback)
Validation-based Protocol (3) • Setiap transaksi harus dijalankan melalui ketiga fase dengan urutan seperti yang dijelaskan sebelumnya.akan tetapi, semua fase dalam pengeksekusian transaksi secara konkuren dapat terjadi pada waktu yang bersamaan. • Fase pembacaan dan fase penulisan sudah cukup jelas. • Fase yang harus ditelaah lebih jauh adalah fase validasi. Untuk melakukan uji validasi, kita perlu mengetahui berbagai fase transaksi Ti yang sedang berlangsung. Kita akan mengasosiasikan tiga buah timestamp berbeda terhadap transaksi Ti, sebagai berikut: – Start(Ti), waktu dimana Ti memulai eksekusinya – Validation(Ti), waktu dimana Ti selesai melakukan fase pembacaan dan memulai fase validasi – Finish(Ti), waktu dimana Ti menyelesaikan fase penulisan
Validation-based Protocol (4) • Dalam menentukan urutan serializability dengan teknik timestamp-ordering dengan menggunakan nilai timestamp validation(Ti). Karena itu, nilai TS(Ti)= validation(Ti). • Jika misalnya ada transaksi lain, Tj dan Tk, dan jika TS(Tj) < TS(Tk), maka setiap schedule yang dihasilkan harus ekuivalen dengan schedule serial dimana transaksi Tj muncul sebelum Tk • Alasan memilih validation(Ti) ketimbang Start(Ti) sebagai timestamp transaksi Ti adalah karena kita dapat mengharapkan waktu tanggap lebih cepat yang dapat diberikan, sehingga tingkat konflik di antara transaksitransaksi menjadi lebih kecil
Validation-based Protocol (5) • Uji validasi untuk transaksi Tj mensyaratkan bahwa, untuk semua transaksi Ti, dengan TS(Ti) < TS(Tj), salah satu dari dua kondisi berikut harus dapat dipenuhi, yaitu: – Finish(Ti) < Start(Tj). Karena Ti menyelesaikan ekesekusinya sebelum Tj dimulai, urutan serializability dapat dipelihara – Himpunan satuan data yang ditulis oleh Ti tidak beririsan dengan himpunan satuan data yang dibaca oleh Tj, dan Ti menyelesaikan fase penulisan-nya sebelum Tj mulai fase validasinya (Start(Tj) < Finish(Ti) < Validation(Tj)). Kondisi ini menjamin bahwa operasi penulisan Ti dan Tj tidak saling bersinggungan. Karena penulisan dalam Ti, tidak mempengaruhi pembacaan dalam Tj, dan karena Tj tidak dapat mempengaruhi pembacaan Ti, maka urutan serializability juga dapat dipelihara
Validation-based Protocol (6) • Lihat transaksi T7 dan T8 sebelumnya. Katakanlah, TS(T7) < TS(T8).maka fase validasi akan berhasil dalam schedule berikut ini. Ingatlah bahwa penulisan/perubahan akhir ke basis data hanya dilakukan setelah fase validasi dari T8. Karena itu, T7 akan membaca nilai-nilai lama dari rekening B dan A, dan akhirnya schedule ini bersifat serializable T7
T8
read (B) read (B) B := B - 100000 read (A) A := A + 100000 read (A) < validas i> display (A+B)
< Validasi > write (B) write (A)
Validation-based Protocol (7) • Skema validasi ini secara otomatis terlindung dari penjalaran rollback (dimana semua transaksi di-rollback akibat adanya sebuah transaksi yang di-rollback pada sebuah pelaksanaan transaksi yang konkuren), karena penulisan aktual ke basis data hanya akan dikerjakan setelah transaksi yang mengandung operasi write telah di-commit
Penanganan Deadlock (1) • Deadlock merupakan kondisi dimana ada lebih dari satu transaksi berada dalam keadaan menunggu (waiting state) untuk melakukan akses/perubahan terhadap suatu satuan data yang rupanya sedang dikunci oleh transaksi lain yang juga sedang menunggu. • Lebih jauh dikatakan, ada sekumpulan transaksi yang sedang menunggu (T0, T1,….., Tn) sedemikian hingga T0 menunggu pemakaian sebua satuan data yang sedang dipegang oleh T1, dan T1 sedang menunggu pemakaian sebuah satuan data yang sedang dipegang oleh T2, dst hingga Tn-1 sedang menunggu pemakaian sebuah satuan data yang sedang dipegang Tn, dan Tn sedang menunggu pemakaian sebuah satuan data yang sedang dipegang oleh T0. • Tidak satupun dari transaksi tersebut dapat beranjak dari situasi tsb. Satu-satunya cara untuk melepaskan diri dari situasi ini adalah dengan melakukan aksi drastis, seperti membatalkan sejumlah transaksi yang terlihat dalam kondisi
Penanganan Deadlock (2) • Ada dua metode dasar untuk mengatasi masalah deadlock tsb, yaitu: – Pencegahan deadlock (deadlock-prevention) untuk menjamin bahwa sistem tsb tidak pernah memasuki kondisi deadlock – Pendeteksian dan pemulihan deadlock (deadlock-detection and deadlock-recovery), kita dapat mengijinkan sistem memasuki kondisi deadlock, dan kemudian berusaha untuk mengatasinya dengan memanfaatkan skema pendetksian dan pemulihan deadlock
Kedua metoda ini bisa berdampak pada terjadinya pembatalan transaksi (rollback). Metode pertama umum digunakan jika sistem sering mengalami kondisi deadlock, tapi jika tidak metode kedua akan lebih efisien. • skema deteksi dan pemulihan deadlock akan menyebabkan tambahan beban (overhead) yang tidak hanya meliputi biaya waktu eksekusi (run-time) dalam pemeliharaan informasi yang penting dan eksekusi algoritma pendeteksian, tetapi juga akibat potensi kehilangan data pada saat proses pemulihan (recovery) dari kondisi deadlock tersebut
Pencegahan Deadlock (1) • Ada dua pendekatan dalam mencegah terjadinya deadlock. – Pendekatan 1 menjamin bahwa tidak ada siklus penantian yang terjadi dengan mengantrikan permintaan penguncian, atau dengan mensyaratkan semua penguncian harus terpenuhi secara bersamaan. – Pendekatan 2 lebih mendekati cara pemulihan deadlock (deadlock recovery) dan membentuk pembatalan transaksi (rollback) sebagai ganti penantian penguncian, ketika penantian tersebut potensial menghasilkan kondisi deadlock.
• Skema yang paling sederhana untuk pendekatan 1 mensyaratkan bahwa setiap transaksi mengunci semua satuan datanya sebelum eksekusi dimulai. Lebih jauh lagi , semua satuan data tsb dikunci sekaligus atau tidak sama sekali. • Ada dua kelemahan dalam protokol ini: – Seringkali sulit untuk memperkirakan satuan data yang mana saja yang perlu dikenai penguncian, sebelum transaksi dimulai – Pemakaian satuan data bisa menjadi sangat rendah, karena banyak satuan data yang dikenai penguncian tetapi sebenarnya tidak digunakan untuk jangka waktu yang lama
Pencegahan Deadlock (2) • Skema yang lain untuk melakukan pencegahan deadlock adalah dengan memaksakan sebuah pengurutan parsial dari semua satuan data, dan mengharuskan transaksi melakukan penguncian ke suatu satuan data hanya dalam urutan yang ditentukan dalam urutan parsial tadi. Kita dapat melihat hal ini dalam protokol hirarkis • Pendekatan kedua untuk pencegahan deadlock adalah dengan menggunakan pemilikan (preemption) yang dipadukan dengan pembatalan transaksi (rollback). • Dalam proses pemilikan, ketika sebuah transaksi T2 meminta penguncian pada suatu satuan data yang sedang dipegang oleh transaksi T1, penguncian yang diberikan pada T1 dapat dianulir dengan membatalkan (rollback) transaksi T1 untuk kemudian memberikan hak penguncian pada T2 • Untuk mengontrol kepemilikan tsb, kita menerapkan timestamp yg unik pada setiap transaksi. Sistem menggunakan timestamp ini hanya untuk memutuskan
Pencegahan Deadlock (3) • Mekanisme penguncian tetap digunakan untuk mengendalikan konkurensi, jika sebuah transaksi dibatalkan, ia tetap memiliki timestamp lamanya ketika transaksi tsb dimulai kembali. • Ada dua bentuk skema pencegahan deadlock yang menggunakan timestamp ini: – Skema wait-die yang didasarkan pada teknik ketiadaan pemilikan (non-preemptive technique). Ketika transaksi Ti membutuhkan sebuah satuan data yang sedang dipegang oleh Tj, Ti dibolehkan untuk menunggu hanya jika ia memiliki timestamp yang lebih kecil dari Tj (jadi Ti lebih dulu ketimbang Tj). Jika tidak, Ti akan dibatalkan (mati). Sebagai contoh, katakanlah bahwa kita memiliki transaksi T9, T10 dan T11 yang masing -masing memiliki timestamp 5, 10, dan 15. Jika T9 membutuhkan sebuah satuan data yang sedang dipegang oleh T10, maka T9 akan menunggu. Jika T11 membutuhkan satuan data yang sedang dipegang oleh T10, maka T11 akan dibatalkan (rollback) – Skema wound-wait yang didasarkan pada teknik kepemilikan (preemptive technique) dan merupakan lawan dari skema pertama. Ketika transaksi Ti membutuhkan satuan data yang sedang dipegang oleh Ti, Ti dibolehkan menunggu hanya jika ia memiliki timestamp yang lebih besar dari Tj (jadi Ti lebih belakangan ketimbang Tj). Jika tidak, Tj akan dibatalkan (Tj dianulir oleh Ti). Pada contoh kasus yang sama, yang melibatkan transaksi T9, T10 dan t11, jika T9 membutuhkan satuan data yang dipegang oleh T10, maka satuan data tsb akan diambil alih dari T10, dan T10 akan dibatalkan. Jika T11 membutuhkan satuan data yang dipegang T10, maka T11 akan menunggu.
Pencegahan Deadlock (4) • Kapanpun transaksi dibatalkan (roll back ), harus pula dihindari kondisi tidak menguntungkan lainnya yang disebut s t a r v a t i o n , yaitu terjadinya proses pembatalan transaksi (roll back ) terus menerus dan tidak pernah mengalami kemajuan. ) dapat • Kedua skema diatas ( w o u n d - w a i t dan wait-die menghindari terjadinya s t a r v a t i o n : pada setiap waktu, ada sebuah transaksi dengan nilai timestamp terkecil. • Transaksi ini tidak dapat dikenai roll back di kedua skema. Karena nilai timestamp selalu meningkat, dan karena transaksi tidak diberi nilai timestamp yang baru ketika ia roll back , maka transaksi yg di-roll-back tsb suatu saat akan memiliki nilai timestamp terkecil. Karena itu, tidak akan di-roll back terus menerus
Pencegahan Deadlock (5) • Perbedaan penting dalam cara beroperasinya kedua skema: – Dalam skema wait-see , transaksi yg lebih dahulu (dengan timestamp lebih kecil) harus menunggu hingga transaksi yang lebih belakangan melepaskan pengunciannya terhadap suatu satuan data. Dengan demikian, semakin tua usia sebuah transaksi, semakin sering ia mengalami situasi menunggu. Dalam skema w o u n d - w a i t , transaksi yg lebih dahulu tidak akan menunggu transaksi yg belakangan. – Dalam skema wait-see , jika sebuah transaksi Ti mati dan dibatalkan karena ia membutuhkan satuan data yg sedang dipegang oleh Tj, maka Ti dapat memiliki urutan permintaan yg sama ketika eksekusinya diulangi. Jika satuan data tsb masih dipegang oleh Tj, maka Ti bisa dimatikan kembali. Dengan begitu, Ti bisa dimatikan beberapa kali sebelum mendapatkan satuan data yang dibutuhkannya. – Dalam skema w o u n d - w a i t , yang terjadi justru sebaliknya. Transaksi Ti dibatalkan kerena Tj membutuhkan satuan data yg sedang dipegang oleh Ti. Ketika Ti dimulai kembali dan membutuhkan satuan data yg sama yg sedang dipegang oleh Tj, maka Ti akan menunggu. Karena itu, peristiwa roll-back akan lebih sedikit terjadi dalam skema w o u n d - w a i t .
Skema berbasis timeout(1) • Pendekatan sederhana lainnya dalam penanganan deadlock didasarkan pada pemakaian batas waktu penguncian (lock timeouts). • Dalam pendekatan ini, sebuah transaksi yg membutuhkan sebuah penguncian akan menunggu selama batas waktu yg telah ditentukan, • Jika hak penguncian tidak juga diberikan hingga batas waktu tsb dilewati, maka transaksi tsb telah mengalami timeout dan ia telah membatalkan dirinya sendiri dan mengulangi eksekusinya kembali. Jika ternyata ada kondidi deadlock yg terjadi, satu atau lebih transaksi yg terlibat dalam kondisi tsb akan memasuki masa timeout dan membatalkan eksekusinya sehingga memungkinkan transaksi lainnya untuk meneruskan prosesnya.
Skema berbasis timeout(2) • Skema timeout ini mudah untuk diterapkan, dan bekerja dengan baik jika transaksi-transaksi yg terlibat merupakan transaksi yg pendek dan jika waktu tunggu yg lama mengarah pada terjadinya deadlock . • Namun demikian, secara umum akan sukar untuk memutuskan berapa lama sebuah transaksi harus menunggu sebelum kondisi timeout dicapai. • Jika terlalu lama, masa tunggu yg tidak perlu akan terjadi di saat kondisi deadlock memang sudah terjadi. Tapi jika terlalu cepat, transaksi bisa saja dibatalkan (roll back ) pada saat sebenarnya deadlock tidak terjadi, tetapi karena adanya transaksi yg memang lama eksekusinya • Kondisi starvation juga dapat terjadi dalam skema ini. Dengan kelemahan-kelemahan tsb, skema berbasis timeout ini jarang digunakan.
Pendeteksian dan pemulihan deadlock • Jika sebuah sistem tidak memanfaatkan protokol yg bebas dari kondisi deadlock , maka skema pendeteksian dan pemulihan deadlock harus digunakan • Sebuah algoritma yg memonitor keadaan sistem digunakan secara periodik untuk menentukan apakah deadlock terjadi atau tidak. Jika memang telah terjadi,maka sistem harus berusaha memulihkan sistem tsb dari kondisi deadlock tsb • Untuk melakukan hal itu, sistem harus: – Memelihara cukup informasi yg berkaitan dengan alokasi satuan data yg sedang digunakan transaksi dan juga satuan data yg sedang dibutuhkan oleh transaksi-transaksi tsb – Menyediakan sebuah algoritma yg menggunakan informasi ini untuk menentukan apakah sistem telah berada dalam kondisi deadlock atau tidak – Memulihkan sistem dari kondisi deadlock ketika algoritma tsb dapat mendeteksi adanya deadlock .
Pendeteksian deadlock (1) • Deadlock dapat digambarkan dengan lebih rinci dengan memanfaatkan perangkat graph yg disebut graph wait-for . Graph ini terdiri atas pasangan G = (V,E), dimana V mewakili sekumpulan simpul dan E mewakili sekumpulan busur. • Sekumpulan simpul terdiri atas semua transaksi di dalam sistem. Setiap elemen dalam himpunan simpul E merupakan pasangan Ti Tj, jika Ti Tj ada di dalam E, maka ada busur berarah dari transaksi Ti ke transaksi Tj yg menunjukkan bahwa transaksi Ti sedang menunggu transaksi Tj untuk melepaskan penguncian pada satuan data yang dibutuhkan Ti. • Ketika transaksi Ti membutuhkan satuan data yg sedang dipegang oleh transaksi Tj, maka busur Ti Tj ditambahkan ke dalam graph wait-for . Busur ini akan dihapuskan hanya ketika transaksi Tj telah melepaskan satuan data yang dipegangnya yg dibutuhkan oleh Ti
Pendeteksian deadlock (2) • Sebuah deadlock akan terjadi di dalam sistem jika dan hanya jika, dalam graph wait-for tsb terdapat sebuah siklus. Setiap transaksi yg terlibat dalam sebuah siklus dikatakan terkena deadlock. • Untuk mendeteksi deadlock , sistem perlu mengelola graph ini dan secara periodik menjalankan algoritma untuk memeriksa ada tidaknya siklus di dalam graph tersebut. • Untuk mengilustrasikan konsep ini, perhatikan graph berikut ini yg menunjukkan situasi: – Transaksi T12 yg sedang menunggu transaksi T13 dan T14 – Transaksi T14 yg sedang menunggu transaksi T13 – Transaksi T13 yg sedang menunggu transaksi T15 T13
T12
T14
T15
Pendeteksian deadlock (3) • Karena graph di atas tidak memiliki siklus, maka sistem tidak berada dalam kondisi deadlock . • Anggaplah sekarang transaksi T15 membutuhkan satuan data yg sedang dipegang oleh T14. busur T15 T14 ditambahkan pada graph di atas, menghasilkan sebuah kondisi sistem yang baru berikut ini
T13
T15
T12
T14
•
Maka pada saat ini, graph mengandung sebuah siklus T13 T15 T14 T13 yang mengakibatkan transaksi T13, T14, dan T15 mengalami kondisi deadlock
Pendeteksian deadlock (4) • Untuk itu, muncul pula pertanyaan tentang kapan kita harus menjalankan algoritma untuk pendeteksian kondisi deadlock tersebut? Jawaban atas pertanyaan ini tergantung pada kedua faktor berikut ini: – Seberapa sering sebuah deadlock terjadi – Seberapa banyak transaksi yg terkena dampak atas terjadinya deadlock • Jika deadlock sering terjadi, maka algoritma pendeteksian deadlock harus juga lebih sering diaktifkan. Satuan-satuan data yg dialokasikan untuk transaksi-transaksi yg mengalami deadlock tidak akan diperoleh oleh transaksi lain hingga kondisi deadlock tsb diatasi. • Selanjutnya, jumlah siklus dalam graph tersebut bisa saja bertambah. Dalam kondisi terburutk, maka kita dapat mengaktifkan algoritma pendeteksian deadlock ini setiap kali sebuah permintaan pengalokasian data tidak dapat dipenuhi dengan segera.
Pemulihan dari deadlock (1) • Ketika algoritma pendeteksian deadlock dapat mengetahui terjadinya deadlock , sistem harus melakukan langkah pemulihan (recovery ). Solusi yg paling umum adalah dengan menjalankan proses roll back pada satu atau beberapa transaksi untuk lepas dari kondisi deadlock . • Ada tiga aksi yg harus dilakukan: – Pemilihan korban. Pada sekumpulan transaksi yg mengalami deadlock , kita harus menentukan transaksi mana saja yg akan dibatalkan (di-roll back). Kita harus me-roll back transaksi dengan ongkos yg minimum. Sayangnya, kriteria minimum di sini juga sukar ditentukan. Banyak faktor yg dapat menentukan ongkos yg harus dibayar jika dilakukan roll back, seperti: • Berapa lama transaksi-transaksi tsb telah dihitung, dan berapa lama lagi transaksi tsb akan diproses hingga selesai. • Berapa banyak satuan data yg digunakan transaksi tsb • Berapa banyak satuan data lagi yg diperlukan transaksi tsb hingga selesai • Berapa banyak transaksi yg akan terlibat dalam proses roll back tsb
