Concurrency Control DBMS

IKHTISAR Latar Belakang Concurrency Control Konsep Concurrency Control Locking

Concurrency Control Latar Belakang Tujuan utama dalam pengembangan database adalah membuat banyak pengguna bisa mengakses data secara bersamaan. Pengaksesan data ini tidak bermasalah jika semua  pengguna hanya membaca data dan mereka tidak mengganggu satu sama lain Tapi ketika dua pengguna atau lebih mengakses database yang sama secara bersamaan dan salah satu melakukan perubahan terhadap data, maka hal ini akan dapat menimbulkan adanya data yang tidak konsisten (inconsistency data)

Concurrency Control Konsep Untuk mengatasi adanya kemungkinan inconsistency data, maka dibutuhkan adanya suatu mekanisme yang mengatur jalannya transaksi pengaksesan data yang sama tersebut, Mekanisme ini dikenal dengan istilah concurrency control Concurrency control  adalah  proses pengaturan operasi–operasi dalam banyak transaksi yang berjalan secara simultan  pada database tanpa mengganggu operasi pada transaksi lainnya sehingga dapat menghasilkan data yang konsisten

Concurrency Control Teknik Ada dua teknik concurrency control utama yang mengijinkan transaksi untuk berjalan dengan aman dalam subjek paralel untuk constraint tertentu, yaitu locking dan metode timestamp tertentu. Locking dan timestamping adalah pendekatan konservatif karena mereka menyebabkan transaksi ditunda dalam kasus mereka konflik dengan transaksi lain pada beberapa waktu di masa yang akan datang. Metode optimistik, didasarkan pada premis bahwa konflik itu jarang ditemui, jadi mereka mengijinkan transaksi untuk lanjut tidak tersinkronisasi dan hanya mengecek konflik di bagian akhir, ketika transaksi melakukan operasi commit

Locking Locking adalah sebuah prosedur yang digunakan untuk mengendalikan akses bersamaan ke data. Ketika sebuah transaksi sedang mengakses database, sebuah lock mungkin menolak akses ke transaksi lain untuk mencegah hasil yang salah. Ada dua macam lock, yaitu shared lock dan exclusive lock yang harus digunakan sebelum melakukan akses membaca ataupun menulis terhadap database. Penggunaan lock ini adalah untuk menjaga konsistensi data didalam database.

Lock-Based Protocols Merupakan suatu cara yang digunakan untuk tetap menjaga serializability pada data yang diakses oleh lebih dari suatu transaksi. Yaitu, apabila satu transaksi mengakses sebuah item data maka tidak akan ada transaksi yang dapat memodifikasi data tersebut. Ada dua jenis mode penguncian dasar yang digunakan dalam mekanisme ini yaitu: Bersama (Shared). Tunggal (Exclusive)

Lock-Based Protocols Bersama (Shared). Jika sebuah transaksi Ti  dapat melakukan penguncian dengan mode ini (dilambangkan dengan S) terhadap item data Q, maka Ti  dapat membaca, tapi tidak dapat mengubah nilai Q tersebut, Lock-S(Q) Tunggal (Exclusive). Jika sebuah transaksi Ti  dapat melakukan penguncian dengan mode ini (dilambangkan dengan X) terhadap item data Q, maka Ti  dapat membaca maupun mengubah nilai tersebut Lock-X(Q)

Lock-Based Protocols Hal yang harus diperhatikan : Setiap transaksi harus meminta lock apabila akan melakukan operasi/mengakses  terhadap suatu data. Misalkan data  Q, mode-lock yang diterapkan terhadap data Q harus sesuai dengan operasi yang akan dilakukan. Transaksi meminta lock terhadap suatu data, kepada concurrency control manager. Operasi terhadap Q dapat dilakukan transaksi T apabila concurrency control manager memberikan grant (hak istimewa) lock yang diminta

Lock-Based Protocols Contoh suatu transaksi yg menjalankan locking: T2: lock-S(A); read (A); unlock(A); lock-S(B); read (B); unlock(B); display(A+B) Locking seperti di atas tidak cukup untuk menjamin serializability - jika A dan B ter-update diantara pembacaan A dan B, jumlah yang ditampilkan akan salah. Protokol penguncian adalah seperangkat aturan yg diikuti oleh semua transaksi yg meminta dan melepaskan Lock. Protokol penguncian melakukan pembatasan pada set schedules.

Kelemahan pada Lock-Based Protocols Schedule parsial T3 atau T4 dapat melakukan – mengeksekusi lock-S(B) menyebabkan T4 menunggu T3 untuk melepaskan lock pada B, ketika mengeksekusi lock-X (A) menyebabkan T3 menunggu T4 untuk melepaskan lock pada A Situasi tersebut disebut deadlock Untuk menangani deadlock satu dari T3 atau T4 harus melakukan roll back, sehingga lock tsb bisa dilepaskan

Two-phase locking protokol yang menjamin jadwal conflict-serializable Protocol ini menginginkan bahwa setiap transaksi yang akan menjalankan penguncian dan melepaskan penguncian harus melalui dua fase atau tahapan, yaitu: Fase Pertumbuhan (Growing Phase). Sebuah transaksi dapat melakukan sejumlah penguncian tetapi belum satupun melepaskan pengunciannya. Fase Pelepasan (Shrinking Phase). Sebuah transaksi dapat melepaskan sejumlah penguncian , tetapi belum melakukan penguncian yang baru.

Two-phase locking Pada awalnya, sebuah transaksi akan berada dalam fase pertumbuhan. Transaksi tersebut akan melakukan penguncian sebanyak yang dibutuhkan. Ketika transaksi mulai melepaskan sebuah penguncian, ia akan mulai memasuki fase pelepasan, tanpa ada permintaan penguncian berikutnya

Two-phase locking Two-phase locking tdk menjamin bebas dari deadlocks Cascading roll-back mungkin terjadi pada two-phase locking. Untuk menghindari hal ini, digunakan protokol dimodifikasi yg disebut strict two-phase locking. Dimana suatu transaksi harus memegang semua kunci eksklusif sampai transaksi tsb melakukan commit/Abort. Rigorous two-phase locking bahkan lebih ketat: di sini semua kunci dipegang sampai pelaksanaan commit/abort. Dalam protokol ini transaksi dapat dibuat serialized dalam urutan di mana mereka melaksanakan Commit

Implementasi Locking A lock manager can be implemented as a separate process to which transactions send lock and unlock requests The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock) The requesting transaction waits until its request is answered The lock manager maintains a data-structure called a lock table to record granted locks and pending requests The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked

Lock Table Black rectangles indicate granted locks, white ones indicate waiting requests Lock table also records the type of lock granted or requested New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted If transaction aborts, all waiting or granted requests of the transaction are deleted lock manager may keep a list of locks held by each transaction, to implement this efficiently

Graph-Based Protocols Graph-based protocols are an alternative to two-phase locking Impose a partial ordering  on the set D = {d1, d2 ,..., dh} of all data items. If di  dj then any transaction accessing both di and dj must access di before accessing dj. Implies that the set D may now be viewed as a directed acyclic graph, called a database graph. The tree-protocol is a simple kind of graph protocol.

Tree Protocol Only exclusive locks are allowed. The first lock by Ti may be on any data item. Subsequently, a data Q can be locked by Ti only if the parent of Q is currently locked by Ti. Data items may be unlocked at any time. A data item that has been locked and unlocked by Ti cannot subsequently be relocked by Ti

Graph-Based Protocols The tree protocol ensures conflict serializability as well as freedom from deadlock. Unlocking may occur earlier in the tree-locking protocol than in the two-phase locking protocol. shorter waiting times, and increase in concurrency protocol is deadlock-free, no rollbacks are required Drawbacks Protocol does not guarantee recoverability or cascade freedom Need to introduce commit dependencies to ensure recoverability Transactions may have to lock data items that they do not access. increased locking overhead, and additional waiting time potential decrease in concurrency Schedules not possible under two-phase locking are possible under tree protocol, and vice versa.

Dead Lock Deadlock adalah jalan buntu yang dapat terjadi ketika dua atau lebih transaksi masing-masing menunggu lock yang sedang dipegang oleh transaksi lainnya untuk dilepas. Cara untuk menghancurkan deadlock, yaitu abort satu atau lebih transaksi. Ada tiga cara untuk menangani deadlock, yaitu timeout, deadlock prevention dan deadlock detection and recovery.

Deadlock Handling Consider the following two transactions: T1: write (X) T2: write(Y) write(Y) write(X) Schedule with deadlock T1 T2 lock-X on X write (X) lock-X on Y write (X) wait for lock-X on X wait for lock-X on Y

Penanganan Dead Lock Timeout Pendekatan sederhana pada pencegahan deadlock adalah berdasarkan lock timeout. Dengan pendekatan ini, sebuah transaksi yang meminta sebuah lock akan menunggu hanya sampai periode waktu tertentu yang didefinisikan sistem

Penanganan Dead Lock Deadlock Prevention protocols memastikan bahwa sistem tdk pernah memasuki status deadlock Beberap strategi: Mengharuskan setiap transaksi mengunci semua item data sebelum dimulai eksekusi (predeclaration). Memaksakan pengurutan parsial dari semua item data dan mengharuskan transaksi dapat mengunci item data hanya dalam urutan yang ditentukan oleh urutan parsial (graph-based protocol).

Deadlock Prevention Dengan memesan transaksi menggunakan timestamp transaksi. Dua algoritma telah ditemukan oleh Rosenkrantz. Algoritma pertama, Wait-Die, mengijinkan hanya transaksi yang lebih tua untuk menunggu yang lebih muda, jika tidak transaksi dibatalkan (die/mati) dan restart dengan timestamp yang sama, sehingga lama kelamaan transaksi tersebut akan menjadi transaksi aktif tertua dan tidak akan mati. Algoritma kedua, Wound-Wait, menggunakan pendekatan simetrikal. Hanya transaksi yang lebih muda yang dapat menunggu untuk yang lebih tua. Jika transaksi yang lebih tua meminta lock yang dipegang oleh transaksi yang lebih muda, transaksi yang lebih muda digagalkan

Penanganan Dead Lock Deadlock Detection Deadlock detection biasanya ditangani oleh konstruksi wait-for graph (WFG) yang menunjukkan ketergantungan transaksi, yaitu transaksi Ti tergantung pada Tj jika transaksi Tj memegang lock pada sebuah item data yang ditunggu oleh Ti. WFG adalah sebuah directed graph G = (N, E ) yang terdiri dari satu set node N dan satu set directed edge E, yang dikonstruksi sebagai berikut Buat sebuah node untuk setiap transaksi. Buat sebuah directed edge Ti → Tj , jika transaksi Ti menunggu untuk melakukan lock sebuah item yang sedang di-lock oleh T

Deadlock Detection Wait-for graph with a cycle The system is in a deadlock state if and only if the wait-for graph has a cycle. Must invoke a deadlock-detection algorithm periodically to look for cycles Wait-for graph without a cycle Wait-for graph with a cycle

Deadlock Recovery When deadlock is detected : Some transaction will have to rolled back (made a victim) to break deadlock. Select that transaction as victim that will incur minimum cost. Rollback -- determine how far to roll back transaction Total rollback: Abort the transaction and then restart it. More effective to roll back transaction only as far as necessary to break deadlock.