Distributed System Genap 2011/2012 8 Management Transaksi Dahlia Widhyaestoeti, S.Kom dahlia.widhyaestoeti@gmail.com dahlia74march.wordpress.com
What is a Transaction? Setiap tindakan yang membaca dari dan / atau menulis ke database dapat terdiri dari SELECT Sederhana untuk menghasilkan daftar isi tabel Serangkaian pernyataan UPDATE terkait untuk mengubah nilai-nilai dari atribut di berbagai tabel Serangkaian pernyataan INSERT untuk menambahkan baris ke satu atau lebih tabel Kombinasi SELECT, UPDATE, dan pernyataan INSERT Sebuah unit logis dari pekerjaan yang harus diselesaikan baik seluruhnya atau dibatalkan Transaksi yang berhasil mengubah database dari satu negara yang konsisten yang lain (Most real-world database transactions) Kebanyakan dunia nyata transaksi database dibentuk oleh dua atau lebih permintaan database Setara dengan pernyataan SQL tunggal dalam program aplikasi atau transaksi
Contoh Transaksi :
Sifat Transaksi : Atomicity Mensyaratkan bahwa semua operasi (SQL permintaan) dari transaksi akan selesai, jika tidak, maka transaksi dibatalkan Sebuah transaksi diperlakukan sebagai satu unit Consistency Tiap transaksi wajib konsisten Sifat konsisten adalah tanggung jawab pengguna Transaksi harus mengubah database dari satu stata konsisten ke stata lainnya/ berikutnya. Isolation Transaksi diisolasi atau dilindungi dari pengaruh scheduling konkuren transaksi lain. Transaksi dieksekusi secara terpisah dari yang satu dengan yang lainnya. Durability Tiap transaksi yang sukses, efeknya tetap bertahan bahkan jika sistem mengalami crash sebelum semua perubahannya direfleksikan pada disk. Secara permanen direkam kedalam database dan tidak akan hilang dikarenakan kegagalan berikutnya.
Output Transaksi Sukses transaksi dikatakan commited dan database mencapai stata baru/stata berikutnya. Gagal transaksi dikatakan aborted, dan database harus dikembalikan ke stata tetap sebelum dilakukannya transaksi. Transaksi seperti ini disebut roll back atau undone. Transaksi yang committed tidak dapat digagalkan. Transaksi yang digagalkan akan dilakukan rollback yang dapat diproses ulang (restarted) diwaktu mendatang.
State Transition Diagram for Transaction
Transaksi dan Schedule Sebuah transaksi oleh DBMS sebagai sebuah rangkaian, atau daftar, tindakan. Tindakan yang dapat dieksekusi transaksi meliputi baca dan tulis objek database. Selain membaca dan menulis, tiap transaksi harus menentukan commit (selesai dengan sukses) atau abort (terminasi dan meng-undo semua tindakan yang dilakukan) Schedule adalah daftar tindakan (membaca, menulis, meng-abort, atau meng-commit) dari sekumpulan transaksi. T1 R(C) W(C) T2 R(B) W(B) Gambar schedule disamping tidak berisi tindakan membatalkan atau menjalankan transaksi. Schedule yang berisi abort dan commit untuk tiap transaksi yang tindakannya terdaftar disebut schedule lengkap. Jika tindakan transaksi berbeda tidak diinterleave, yaitu transaksi dieksekusi dari awal sampai selesai, satu per satu kita sebut dengan schedule serial. Schedule melibatkan dua transaksi
Serializability Serializability schedule pada set S commited transaction merupakan schedule yang pengaruhnya pada contoh database konsisten dijamin sama dengan beberapa schedule serial lengkap pada S, yaitu contoh database yang dihasilkan dari mengeksekusi contoh schedule, sama dengan contoh database yang dihasilkan dari mengeksekusi transaksi dalam beberapa urutan serial. T1 R(B) W(B) Commit T2 R(B) W(B) Commit Gambar disamping adalah serializable. Meskipun tindakan T1 dan T2 di-interleave, hasil schedule ini sama dengan menjalankan T1 (seluruhnya) dan kemudian menjalankan T2. Secara intuitif, pembacaan T1 dan penulisan B tidak dipengaruhi tindakan T2 pada A, dan efek bersihnya sama jika tindakan tersebut ditukar' dengan schedule serial T1;T2. Serializability Schedule
Situasi Anomali pada Transaksi Tiga situasi anomali dapat digambarkan dalam konteks pada saat tindakan dua transaksi T1 dan T2 saling berkonflik, yaitu : Konflik Write-Read (WR) Konflik Read-Write (RW) Konflik Write-Write (WW)
Membaca Uncommited Data (Konflik - WR) Dirty Read Transaksi T2 dapat membaca objek database A yang telah dimodifikasi oleh transaksi lain T1, yang belum dijalankan. Contoh : T1 mentransfer $100 dari A ke B T2 menambah jumlah A dan B masing-masing sebesar 6% (misalnya, bunga tahunan didepositokan ke dalam 2 rekening tersebut) Misalkan tindakan di-interlave sehingga : 1) Program transfer rekening T1 mengurangi $100 dari rekening A, kemudian 2) Program bunga deposito T2 membaca nilai terbaru rekening A dan B, dan menambah bunga 6% ke masingmasing rekening, kemudian 3) Program transfer rekening mengkredit $100 untuk rekening B. T1 R(B) W(B) Commit T2 R(B) W(B) Commit
Membaca Uncommited Data (Konflik - WR) Hasil schedule ini berbeda dari hasil yang kita peroleh dengan melakukan satu transaksi terlebih dahulu dan kemudian transaksi berikutnya. T1 R(B) W(B) Commit T2 R(B) W(B) Commit Masalah tersebut dapat dilacak dari fakta bahwa nilai A yang ditulis T1 dibaca T2 sebelum T1 menyelesaikan semua perubahan. Masalah umum yang diilustrasikan disini adalah T1 dapat menulis beberapa nilai ke dalam A yang menjadi database tidak konsisten. Asalkan T1 tidak meng-overwrite nilai tersebut dengan nilai A yang benar sebelum committing, maka tidak ada masalah jika T1 dan T2 bekerja dalam urutan serial, karena kemudian T2 tidak akan melihat ketidakkonsistenan (sementara). Sebaliknya, eksekusi ter-interleave dapat menunjukkkan ketidakkonsistenan ini dan menghasilkan keadaan database akhir tidak konsisten.
Unrepeatable (Konflik - RW) Transaksi T2 mungkin mengubah nilai objek A yang telah dibaca tansaksi T1, saat T1 masih dalam proses. Jika T1 mencoba membaca nilai A lagi, maka T1 akan memperoleh hasil berbeda, meskipun sementara A tidak dimodifikasi. Siatuasi ini dapat menimbulkan eksekusi serial dua transaksi; hal ini disebut unrepeatable read.
Meng-overwrite Uncommitted Data (konflik WW) Transaksi T2 dapat meng-overwrite nilai objek A, yang telah dimodifikasi transaksi T1, saat T1 masih dalam proses. Bahkan jika T2 tidak membaca nilai A yang ditulis T1, maka masalah potensial akan muncul. Contoh : Misalkan Hery dan Lary adalah dua karyawan, dan gaji mereka harus tetap sama. Transaksi T1 mengatur gaji mereka $2000 dan Transaksi T2 mengatur gaji mereka $1000 Jika transaksi yang dilakukan dimulai berurutan dari T1 dan T2 keduanya menerima gaji $1000 Jika transaksi yang dilakukan dimulai berurutan dari T2 dan T1 keduanya menerima gaji $2000 Perhatikan bahwa tidak ada transaksi membaca nilai gaji sebelum menulisnya maka penulisan itu disebut blind write.
Meng-overwrite Uncommitted Data (konflik WW) Perhatikan interleaving tindakan T1 dan T2 berikut: T2 mengatur gaji Hery $1000 T1 mengatur gaji Lary $2000 T2 mengatur gaji Lary $1000 dan commit T1 mengatur gaji Hery $2000 dan commit Hasilnya tidak serupa dengan hasil kedua kemungkinan eksekusi serial, dan oleh karena itu, shcedule ter-interleave tidak serializable. Hal ini melanggar standar konsistensi yang diinginkan yaitu kedua gaji tetap sama. Masalahnya adalah kita mempunyai lost update. Transaksi pertama dilakukan, T2 meng-overwrite gaji Lary seperti yang diatur oleh T1. Dalam urutan serial T2 dilanjutkan T1, gaji Lary sebaiknya merefleksikan pembaruan T1 daripada pembaruan T2, tetapi pembaruan T1 'hilang'.
Schedule melibatkan Aborted Transaction Serializable schedule pada transaksi S adalah schedule yang pengaruhnya pada contoh database konsisten dijamin serupa dengan beberapa schedule serial lengkap pada kumpulan commited trasnsaction pada S. Definisi serializability berdasar pada tindakan aborted transaction yang di-undo secara lengkap, yang tidak mungkin dalam beberapa situasi.contoh : 1) Program transfer rekening T1 mengurangi $100 dari rekening A, kemudian 2) Program bunga deposito T2 membaca nilai terbaru rekening A dan B dan menambah bunga 6% kemasing-masing rekening, dan commit, kemudian 3) T1 dibatalkan. Schedul-nya ditunjukan pada gambar T1 Abort T2 R(B) W(B) Commit
Schedule melibatkan Aborted Transaction T1 Abort T2 R(B) W(B) Commit Sekarang, T2 telah membaca nilai untuk A yang seharusnya tidak ada disana. Jika T2 belum commit, kita dapat mengatasi situasi dengan cascading abort T1 dan juga meng-abort T2; Proses ini secara rekursif meng-abort setiap transaksi yang membaca data yang ditulis T2, dan seterusnya. Tetapi, T2 telah di-commit, jadi kita tidak dapat meng-undo tindakan tersebut. Kita sebut schedule tersebut unrecoverable. Dalam recoverable schedule, transaksi hanya di commit setelah semua transaksi yang perubahannya terbaca di-commit. Jika transaksi hanya membaca perubahan commited transaction, maka bukan hanya recoverable schedule, tetapi meng-abort transaksi juga dapat dilakukan tanpa cascading abort transaksi lainnya. Schedule seperti itu disebut avoid cascading abort.
Schedule melibatkan Aborted Transaction Ada masalah potensial lain dalam meng-undo tindakan transaksi. Misalkan Transaksi T2 meng-overwrite nilai objek A yang telah dimodifikasi transaksi T1, saat T1 masih dalam proses, dan T1 selanjutnya abort Semua perubahan T1 ke objek database di-undo dengan memulihkan nilai setiap objek yang dimodifikasi ke nilai objek sebelum perubahan T1. Pada saat T1 di-abort dan perubahannya di-undo dengan cara ini, perubahan T2 juga hilang, bahkan jika T2 memutuskan untuk commit. Misal : awal A mempunyai nilai 5 Diubah oleh T1 menjadi 6 dan oleh T2 menjadi 7 Jika sekarang oleh T1 di-abort, nilai A menjadi 5 lagi. Bahkan jika T2 di-commit, perubahan A juga hilang. Untuk mencegah masalah tersebut ada teknik kontrol konkurensi yang disebut Strict 2PL yang akan dibahas pada bab selanjutnya...
Raghu Ramakrishnan Johannes G, Sistem Manajemen Database, McGrawHIll