Pemrosesan Transaksi Transcaction Processing Penanganan Deadlock dan Contoh

Pemrosesan Transaksi (Transcaction Processing) –Penanganan Deadlock dan Contoh Kasus –Level Isolasi dan Kasus-kasusnya 1

Penanganan Deadlock dan Contoh Kasus • • Perhatikan transaksi di bawah ini: T 1: write (X) T 2: write(Y) write(X) Schedule dengan deadlock T 1 lock-X on X write (X) T 2 lock-X on Y write (X) wait for lock-X on X wait for lock-X on Y 2

Penanganan Deadlock dan Contoh Kasus • Sistem dikatakan deadlock jika ada sekumpulan transaksi yang saling menunggu satu sama lain. • Protokol Pencegahan Deadlock (Deadlock prevention) memastikan bahwa sistem tidak akan masuk ke dalam keadaan deadlock. Beberapa strategi pencegahan: – Masing-masing transaksi me-lock item data sebelum memulai eksekusi. – Menentukan partial ordering dari semua item data dan transaksi hanya dapat me-lock suatu item data sesuai dengan urutan partial ordering tersebut. 3

Penanganan Deadlock dan Contoh Kasus Skema-skema berikut ini menggunakan timestamp transaksi hanya untuk mencegah terjadinya deadlock. • Skema wait-die — non-preemptive – Transaksi yang lebih tua harus menunggu yang lebih muda untuk melepas item data. Transaksi yang lebih muda tidak pernah menunggu yang lebih tua; tetapi mereka langsung di-rollback. – Transaksi dapat “mati” berkali-kali sebelum memperoleh item data yang diinginkan. • Skema wound-wait — preemptive – Transaksi yang lebih tua “melukai” (memaksa rollback) transaksi yang lebih muda daripada menunggunya. Transaksi-transaksi yang lebih muda dapat menunggu yang lebih tua. – Kemungkinan lebih sedikit rollback daripada skema waitdie. 4

Penanganan Deadlock dan Contoh Kasus • Baik dalam skema wait-die maupun wound-wait, transaksi yang di-rollback diulang dengan timestamp yang sama. Sehingga transaksi yang lebih tua tetap lebih diutamakan daripada transaksi yang baru, dan kondisi starvation dapat dihindari. • Skema Timeout-Based : – Sebuah transaksi menunggu sebuah lock hanya untuk interval waktu tertentu saja. Setelah itu, jika interval waktu telah dilewati (time-out) maka transaksi dirollback. – Sehingga tidak mungkin terjadi deadlock. – Mudah untuk diimplementasikan; tetapi kondisi starvation dapat terjadi. Juga sulit untuk menentukan nilai yang baik untuk interval timeout. 5

Penanganan Deadlock dan Contoh Kasus Deteksi Deadlock • Deadlock dapat digambarkan sebagai sebuah wait-for graph, yang terdiri dari pasangan G = (V, E), – V adalah sekumpulan verteks (semua transaksi-transaksi di sistem) – E adalah sekumpulan busur (edge), masing-masing merupakan pasangan terurut Ti Tj. • Jika Ti Tj ada di dalam E, maka ada busur langsung dari Ti ke Tj, menyatakan secara tidak langsung bahwa Ti sedang mengunggu Tj untuk melepas sebuah item data. • Ketika Ti meminta sebuah item data yang sedang dipengang oleh Tj, maka busur Ti Tj disisipkan dalam wait-for graph. Busur ini hanya dihapus setelah Tj tidak lagi memegang item data yang dibutuhkan oleh Ti. • Sistem berada dalam state deadlock jika dan hanya jika wait -for graph mempunyai cycle. Harus mengeksekusi algoritma deadlock-detection secara periodik untuk mencari cycle. 6

Penanganan Deadlock dan Contoh Kasus Deteksi Deadlock (lanjt) Wait-for graph tanpa cycle Wait-for graph dengan cycle 7

Penanganan Deadlock dan Contoh Kasus Deadlock Recovery • Ketika Deadlock dideteksi: – Beberapa transaksi harus di-rollback (dibuat sebagai korban) untuk memutuskan deadlock. Pilihlah transaksi yang akan dijadikan korban sehingga menyebabkan cost yang paling kecil. – Rollback – tentukan sejauh mana harus me-rollback transaksi • Total rollback: Abort transaksi dan ulangi lagi (restart). • Lebih efektif untuk me-rollback transaksi hanya sejauh yang dibutuhkan untuk memutus deadlock, tetapi mengharuskan sistem untuk memelihara state semua transaaksi yang sedang berlangsung. – Starvation terjadi jika transaksi yang sama selalu dipilih sebagai “korban” (victim). Sehingga untuk menanggulanginya, masukan banyaknya sebuah transaksi telah di-rollback sebagai cost factor untuk menghindari starvation. 8

Penanganan Deadlock dan Contoh Kasus Operasi insert dan delete • Jika two-phase digunakan : – Operasi delete hanya bisa dilakukan jika transaksi yang mempunyai operasi tersebut mempunyai exclusive lock terhadap tuple yang akan di-delete. – Transaksi yang meng-insert tuple baru ke dalam database diberi exclusive lock terhadap tuple tersebut. • Operasi insert dan delete dapat membawa kepada suatu fenomena yang disebut phantom phenomenon. – Sebuah transaksi yang membaca sebuah relasi (misal. Temukan semua account yang ada di Perryridge) dan transaksi yang meng -insert sebuah tuple pada relasi (insert account baru di Perryridge) akan terjadi konflik karena tidak mengakses tuple yang sama. – Transaksi pembacaan dan insert konflik satu sama lain, tetapi sebenarnya mereka tidak mengakses tuple yang sama. Tuple yang belum ada ini tetap mempengaruhi schedule yang dibangkitkan, konflik yang diakibatkan oleh tuple yang belum ada ini dinamakan phantom phenomenon. 9

Penanganan Deadlock dan Contoh Kasus Operasi insert dan delete (lanjt) • Transaksi yang membaca relasi sebenarnya membaca informasi tuple apa yang ada di dalam suatu relasi, sementara transaksi yang menyisipkan (insert) sebuah tuple meng-update informasi yang sama. – Informasi ini harus di-lock. • Satu pemecahan: – Hubungkan sebuah item data dengan sebuah relasi, untuk menyatakan informasi tentang tuple apa saja yang ada di relasi. – Transaksi yang membaca relasi mendapatkan shared lock pada item data. – Transaksi insert atau delete mendapatkan exlusive lock pada item data tersebut. (Catatan: lock pada item data tidak konflik dengan lock pada masing-masing tuple) • Protokol ini memberikan tingkat konkurensi yang rendah untuk operasi insert/delete. • Protokol yang lebih baik adalah protokol index locking. 10

Penanganan Deadlock dan Contoh Kasus Protokol Index Locking • Setiap relasi harus mempunyai sedikitnya satu buah indeks. Akses ke sebuah relasi harus dilakukan hanya melewati salah satu indeks di relasi tersebut. • Sebuah transaksi Ti yang melakukan pencarian harus me-lock semua indeks bucket yang diakses olehnya dalam S-mode. • Sebuah transaksi Ti tidak boleh meng-insert sebuah tuple ti ke dalam relasi r tanpa mengupdate semua indeks ke r. • Ti harus melakukan pencarian (pembacaan) masing-masing indeks ke semua bucket indeks yang mungkin mengandung pointer ke sebuah tuple ti, yang sudah ada sebelumnya, danm memperoleh lock dalam X-mode di semua bucket indeks. Ti juga harus memperoleh lock dalam X-mode pada semua bucket indeks yang diubahnya. • Aturan two-phase locking protocol harus diperhatikan. 11

Level Isolasi dan Kasus-kasusnya • Schedule harus conflict atau view serializable, dan recoverable, untuk menjaga konsistensi database, dan lebih disukai cascadeless. • Suatu kebijakan di mana hanya transaksi yang dieksekusi pada satu waktu membangkitkan serial schedule, tetapi memberikan tingkat konkurensi yang rendah. • Skema Concurrency-control melibatkan suatu tradeoff antara besarnya konkurensi yang dimungkinkan dengan banyaknya ongkos yang didatangkan. • Beberapa skema hanya memungkinkan schedule conflict-serializable yang dibangkitkan, sementara yang lain memungkinkan schedule yang viewserializable tetapi tidak conflict-serializable. 12

Level Isolasi dan Kasus-kasusnya • Data manipulation language (DML) harus memasukan gagasan untuk menentukan sekumpulan aksi yang membentuk sebuah transaksi. • Dalam SQL, sebuah transaksi dimulai secara implisit. • Sebuah transaksi dalam SQL diakhiri oleh: – Commit work (atau commit saja) melakukan commit terhadap transaksi yang sekarang dan memulai yang baru. – Rollback work (atau rollback saja) menyebabkan transaksi yang sedang berlangsung menjadi abort. • Level konsistensi yang dinyatakan oleh SQL-92 adalah: – – Serializable — default Repeatable read Read committed Read uncommitted 13

Level Isolasi dan Kasus-kasusnya • Repeatable read — hanya record-record yang sudah commit saja yang boleh dibaca, pembacaan yang berulang terhadap record yang sama harus memberikan nilai yang sama. Tetapi, transaksi menjadi tidak serializable, sangat mungkin menemukan beberapa record yang di-insert oleh sebuah transaksi tetapai tidak menemukan yang lain (karena belum commit). • Serializable — default • Read committed — hanya record yang sudah commit saja yang boleh dibaca, tetapi pembacaan berulang terhadap record dapat menghasilkan nilai yang berbeda (tetapi sudah commit). • Read uncommitted — Bahkan record yang belum commit dapat dibaca. Tingkat yang lebih rendah dari konsistensi berguna untuk mengumpulkan informasi perkiraan tentang database, misalnya, statistik untuk query optimizer. 14