Concurrency control 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). 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 ( Connolly, 2005, p577 ). Tiga contoh masalah penting yang terkait oleh concurrency, yaitu masalah Lost-Update, masalah Uncommitted Dependency, dan masalah Inconsistent Analysis. Masalah Lost-Update Penjelasan : Transaksi T1 dan T2 mulai pada waktu yang hampir bersamaan, dan keduanya membaca saldo $100. T2 menambah balx $100 menjadi $200 dan menyimpan hasil perubahannya dalam database. Di sisi lain, transaksi T1 mengurangi copy dari balx $10 menjadi $90 dan menyimpan nilai ini dalam database, menimpa hasil update sebelumnya dan akhirnya menghilangkan $100 yang telah ditambahkan sebelumnya ke dalam saldo. Kehilangan update transaksi T2 dapat dihindari dengan mencegah T1 membaca nilai dari balx sampai update T2 telah selesai. Masalah Uncommited Dependency (dirty read) Penjelasan: Transaksi T4 mengubah balx menjadi $200 namun T4 membatalkan transaksi sehingga balx harus dikembalikan ke nilai asalnya, yaitu $100. Namun, pada waktu itu, transaksi T3 telah membaca nilai baru balx ($200) dan menggunakan nilai ini sebagai dasar pengurangan $10, sehingga memberikan saldo yang keliru sebesar $190, yang seharusnya adalah $90. Nilai balx yang dibaca T3 disebut dirty data, yang berasal dari nama alternatifnya, yaitu masalah dirty read. Alasan rollback ini tidaklah penting. Masalahnya adalah transaksinya gagal (error), mungkin mengurangi rekening yang salah. Efeknya adalah asumsi T3 yang menganggap update T4 telah berhasil dijalankan, meskipun selanjutnya perubahannya dibatalkan. Masalah ini dihindari dengan mencegah T3 membaca balx sampai keputusan telah dibuat, yaitu commit atau membatalkan efek T4. Dua masalah di atas mengkonsentrasikan pada transaksi yang mengubah database dan campur tangan mereka bisa membuat database menjadi corrupt. Namun, transaksi yang hanya membaca database bisa juga memberikan hasil yang tidak akurat jika mereka diijinkan untuk membaca hasil bagian dari transaksi yang belum selesai yang secara bersamaan membaca database. Contohnya dijelaskan pada masalah inconsistent analysis. Masalah Inconsistent Analysis Penjelasan: Masalah inconsistent analysis muncul ketika sebuah transaksi membaca beberapa nilai dari database tapi transaksi kedua mengubah beberapa darinya ketika eksekusi transaksi yang pertama. Contohnya, sebuah transaksi yang meringkas data pada sebuah database(contohnya, saldo total) akan mendapat hasil yang tidak akurat jika, ketika berjalan, transaksi lain sedang mengubah database. Pada contoh diatas, ringkasan transaksi T6 sedang berjalan secara bersamaan dengan transaksi T5. Transaksi T6 sedang menjumlahkan saldo rekening x ($100), rekening y ($50), dan rekening z($25). Namun, di tengah jalan, transaksi T5 telah mentransfer $10 dari balx ke balz, sehingga T6 sekarang mempunyai hasil yang salah (lebih besar $10). Serializability dan Recoverability Tujuan protokol concurrency control adalah untuk menjadwalkan transaksi sedemikian rupa sehingga dapat menghindar dari berbagai gangguan, dan juga mencegah tipe-tipe masalah yang digambarkan pada sesi sebelumnya. Satu solusi yang jelas adalah mengijinkan hanya satu transaksi yang berjalan dalam satu waktu. Satu transaksi berstatus commit sebelum transaksi berikutnya diijinkan mulai. Namun, tujuan dari DBMS multi user juga untuk memaksimalkan derajat concurrency atau paralelisme dalam sebuah sistem, sehingga transaksi yang dapat berjalan tanpa mengganggu satu sama lain dapat berjalan secara paralel. Contohnya, transaksi yang mengakses bagian berbeda pada database dapat dijadwalkan bersama tanpa gangguan. Dalam bagian ini, kita memeriksa serializability sebagai sebuah cara untuk membantu mengidentifikasi eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi. Pertama, kita beri beberapa definisi. Schedule Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual ( Connolly, 2005, p580 ). Sebuah transaksi mencakup sebuah urutan operasi yang terdiri dari tindakan baca dan/atau tulis pada database, diikuti oleh sebuah tindakan commit atau abort. Sebuah schedule S terdiri dari sebuah urutan operasi dari sekumpulan n transaksi T1, T2, … Tn, bergantung pada constraint yang dilindungi oleh urutan operasi untuk setiap transaksi pada schedule tersebut. Jadi, untuk setiap transaksi Ti pada schedule S, urutan operasi pada Ti harus sama dengan schedule S. Serial Schedule adalah sebuah schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya tarnsaksi yang mengganggu transaksi lainnya (Connolly, 2005, p580). NonSerial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved (Connolly, 2005, p580). Pada sebuah serial schedule, transaksi dijalankan pada serial order. Contohnya, jika kita mempunyai dua transaksi T1 dan T2, serial ordernya akan menjadi T1 diikuti oleh T2, atau T2 diikuti oleh T1. Lalu, pada eksekusi serial tidak ada interferensi antara transaksi, karena hanya satu transaksi yang berjalan pada satu waktu. Tujuan serializibility adalah untuk menemukan non serial schedule yang mengijinkan transaksi untuk berjalan secara bersamaan tanpa mengganggu satu sama lain, dan kemudian memproduksi sebuah state database yang dapat diproduksi oleh sebuah eksekusi serial. Jika sebuah set transaksi berjalan secara bersamaan, bisa dikatakan bahwa schedule (nonserial) adalah benar jika memproduksi hasil yang sama seperti beberapa eksekusi serial lainnya. Schedule seperti itu disebut serializable. Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin serializability dari transaksi yang jalan bersamaan. Pada serializability, urutan operasi baca dan tulis itu penting. Berikut ini hal – hal yang perlu diperhatikan: Jika dua transaksi hanya membaca satu item data yang sama, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. Jika dua transaksi melakukan operasi membaca ataupun menulis pada item data yang berbeda, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. Jika satu transaksi menulis sebuah item data dan transaksi lain baik membaca ataupun menulis pada item data yang sama, maka urutan eksekusi itu menjadi penting. Anggap schedule S1 yang ditunjukkan oleh gambar (a) di bawah mengandung operasi dari dua transaksi yang sedang berjalan secara bersamaan, yaitu T7 dan T8. Karena operasi tulis pada balx di T8 tidak konflik dengan operasi baca berikutnya pada baly di T7, kita dapat mengubah urutan operasinya untuk memproduksi schedule yang ekuivalen (S2) ditunjukkan oleh gambar (b). Jika kita sekarang juga mengubah urutan dari operasi yang tidak konflik berikut, kita memproduksi serial schedule yang ekuivalen (S3) ditunjukkan oleh gambar (c) di bawah. Ubah urutan write(balx) di T8 dengan write(baly) di T7 Ubah urutan read(balx) di T8 dengan read(baly) di T7 Ubah urutan read(balx) di T8 dengan write(baly) di T7 Keterangan Gambar : (a) nonserial schedule S1 (b) nonserial schedule S2 (c) serial schedule S3, ekuivalen dengan S1 dan S2 Schedule S3 adalah sebuah schedule serial dan karena S1 dan S2 ekuivalen dengan S3, maka S1 dan S2 adalah serializable schedule. Recoverable schedule adalah sebuah schedule di mana, untuk setiap transaksi Ti dan Tj, jika Tj membaca sebuah item data yang sebelumnya ditulis oleh Ti, kemudian operasi commit dari Ti mendahului operasi commit Tj. Teknik Concurrency Control 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. Metode 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 ( Connolly, 2005, p587 ). 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. Jika sebuah transaksi mempunyai sebuah shared lock pada sebuah item data, transaksi tersebut dapat membaca item tapi tidak dapat mengubah datanya ( Connolly, 2005, p588 ). Jika sebuah transaksi mempunyai sebuah exclusive lock pada sebuah item data, transaksi tersebut dapat membaca dan mengubah item data ( Connolly, 2005, p588 ). Lock digunakan dengan cara sebagai berikut: Transaksi apapun yang membutuhkan akses pada sebuah item data harus melakukan lock terhadap item tersebut, meminta shared lock untuk akses membaca saja atau sebuah exclusive lock untuk akses membaca dan menulis. Jika item belum dikunci oleh transaksi lain, lock tersebut akan dikabulkan Jika item sedang dikunci, DBMS menentukan apakah permintaan ini compatible dengan lock saat ini. Jika diminta shared lock pada sebuah item yang sudah mempunyai shared lock terpasang padanya, permintaan itu akan dikabulkan. Selain itu, transaksi harus menunggu sampai lock yang ada terlepas. Sebuah transaksi lanjut memegang lock sampai transaksi tersebut melepasnya baik pada waktu eksekusi ataupun pada waktu transaksi tersebut berakhir (abort atau commit). Efek operasi tulis akan terlihat pada transaksi lain hanya pada waktu exclusive lock telah dilepas. Two Phase Locking adalah sebuah transaksi yang mengikuti protokol two-phase locking jika semua operasi locking mendahului operasi unlock pertama pada transaksi ( Connolly, 2005, p589 ). Aturan-aturannya adalah sebagai berikut : Sebuah transaksi harus mendapatkan sebuah lock pada item sebelum beroperasi pada item tersebut. Lock tersebut bisa berupa baca atau tulis, tergantung dari tipe akses yang dibutuhkan Sebelum transaksi melepaskan sebuah lock, transaksi tersebut tidak akan pernah mendapatkan lock baru lainnya. Deadlock Deadlock adalah jalan buntu yang dapat terjadi ketika dua atau lebih transaksi masingmasing menunggu lock yang sedang dipegang oleh transaksi lainnya untuk dilepas. Hanya ada satu 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. 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. Deadlock Prevention Pendekatan lain untuk mencegah deadlock adalah untuk 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. 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 Tj. Deadlock terjadi jika dan hanya jika WFG mengandung sebuah cycle. Gambar di atas menunjukkan WFG yang menunjukkan deadlock antara dua transaksi.
