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 operasioperasi dalam banyak transaksi yang berjalan secara simultan
pada database tanpa mengganggu operasi pada transaksi lainnya sehingga dapat
menghasilkan data yang konsisten ( Connolly, !!", p"## ). Tiga contoh masalah penting
yang terkait oleh concurrency, yaitu masalah Lost-Update, masalah Uncommitted
Dependency, dan masalah Inconsistent Analysis.
Masalah Lost-Update
Penjelasan $ Transaksi T% dan T mulai pada &aktu yang hampir bersamaan, dan
keduanya membaca saldo '%!!. T menambah bal( '%!! menjadi '!! dan menyimpan
hasil perubahannya dalam database. )i sisi lain, transaksi T% mengurangi copy dari bal(
'%! menjadi '*! dan menyimpan nilai ini dalam database, menimpa hasil update
sebelumnya dan akhirnya menghilangkan '%!! yang telah ditambahkan sebelumnya ke
dalam saldo. +ehilangan update transaksi T dapat dihindari dengan mencegah T%
membaca nilai dari bal( sampai update T telah selesai.
Masalah Uncommited Dependency (dirty read)
Penjelasan$ Transaksi T, mengubah bal( menjadi '!! namun T, membatalkan transaksi
sehingga bal( harus dikembalikan ke nilai asalnya, yaitu '%!!. -amun, pada &aktu itu,
transaksi T. telah membaca nilai baru bal( ('!!) dan menggunakan nilai ini sebagai
dasar pengurangan '%!, sehingga memberikan saldo yang keliru sebesar '%*!, yang
seharusnya adalah '*!. -ilai bal( yang dibaca T. disebut dirty data, yang berasal dari
nama alternati/nya, yaitu masalah dirty read. 0lasan rollback ini tidaklah penting.
Masalahnya adalah transaksinya gagal (error), mungkin mengurangi rekening yang salah.
1/eknya adalah asumsi T. yang menganggap update T, telah berhasil dijalankan,
meskipun selanjutnya perubahannya dibatalkan. Masalah ini dihindari dengan mencegah
T. membaca bal( sampai keputusan telah dibuat, yaitu commit atau membatalkan e/ek
T,. )ua masalah di atas mengkonsentrasikan pada transaksi yang mengubah database
dan campur tangan mereka bisa membuat database menjadi corrupt. -amun, 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 T2 sedang berjalan secara bersamaan dengan transaksi T". Transaksi T2 sedang
menjumlahkan saldo rekening ( ('%!!), rekening y ('"!), dan rekening 3('"). -amun,
di tengah jalan, transaksi T" telah mentrans/er '%! dari bal( ke bal3, sehingga T2
sekarang mempunyai hasil yang salah (lebih besar '%!).
Serializability dan Recoerability
Tujuan protokol concurrency control adalah untuk menjad&alkan transaksi sedemikian
rupa sehingga dapat menghindar dari berbagai gangguan, dan juga mencegah tipe4tipe
masalah yang digambarkan pada sesi sebelumnya. 5atu solusi yang jelas adalah
mengijinkan hanya satu transaksi yang berjalan dalam satu &aktu. 5atu transaksi
berstatus commit sebelum transaksi berikutnya diijinkan mulai. -amun, tujuan dari
)6M5 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 dijad&alkan bersama tanpa gangguan. )alam bagian ini,
kita memeriksa serializability sebagai sebuah cara untuk membantu mengidenti/ikasi
eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi. Pertama, kita
beri beberapa de/inisi.
Schedule
5chedule adalah sebuah urutan dari operasi4operasi oleh satu set transaksi yang jalan
bersamaan yang menjaga urutan operasi pada setiap transaksi indi7idual ( Connolly,
!!", p"8! ). 5ebuah transaksi mencakup sebuah urutan operasi yang terdiri dari
tindakan baca dan9atau tulis pada database, diikuti oleh sebuah tindakan commit atau
abort. 5ebuah schedule 5 terdiri dari sebuah urutan operasi dari sekumpulan n transaksi
T%, T, : Tn, bergantung pada constraint yang dilindungi oleh urutan operasi untuk
setiap transaksi pada schedule tersebut. ;adi, untuk setiap transaksi Ti pada schedule 5,
urutan operasi pada Ti harus sama dengan schedule 5. Serial Schedule adalah sebuah
schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya
tarnsaksi yang mengganggu transaksi lainnya (Connolly, !!", p"8!). NonSerial
Schedule adalah sebuah schedule di mana operasi4operasi dari satu set concurrent
transactions mengalami interleaved (Connolly, !!", p"8!). Pada sebuah serial schedule,
transaksi dijalankan pada serial order. Contohnya, jika kita mempunyai dua transaksi T%
dan T, serial ordernya akan menjadi T% diikuti oleh T, atau T diikuti oleh T%. <alu,
pada eksekusi serial tidak ada inter/erensi antara transaksi, karena hanya satu transaksi
yang berjalan pada satu &aktu. 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. ;ika sebuah set transaksi berjalan secara bersamaan, bisa
dikatakan bah&a 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. 6erikut ini hal hal yang
perlu diperhatikan$
;ika dua transaksi hanya membaca satu item data yang sama, dua transaksi
tersebut tidak mengalami kon/lik dan urutan menjadi tidak penting.
;ika dua transaksi melakukan operasi membaca ataupun menulis pada item data
yang berbeda, dua transaksi tersebut tidak mengalami kon/lik dan urutan menjadi
tidak penting.
;ika satu transaksi menulis sebuah item data dan transaksi lain baik membaca
ataupun menulis pada item data yang sama, maka urutan eksekusi itu menjadi
penting.
0nggap schedule 5% yang ditunjukkan oleh gambar (a) di ba&ah mengandung operasi
dari dua transaksi yang sedang berjalan secara bersamaan, yaitu T# dan T8. +arena
operasi tulis pada bal( di T8 tidak kon/lik dengan operasi baca berikutnya pada baly di
T#, kita dapat mengubah urutan operasinya untuk memproduksi schedule yang ekui7alen
(5) ditunjukkan oleh gambar (b). ;ika kita sekarang juga mengubah urutan dari operasi
yang tidak kon/lik berikut, kita memproduksi serial schedule yang ekui7alen (5.)
ditunjukkan oleh gambar (c) di ba&ah.
Ubah urutan &rite(bal() di T8 dengan &rite(baly) di T#
Ubah urutan read(bal() di T8 dengan read(baly) di T#
Ubah urutan read(bal() di T8 dengan &rite(baly) di T#
!eteran"an #ambar $
(a) nonserial schedule 5%
(b) nonserial schedule 5
(c) serial schedule 5., ekui7alen dengan 5% dan 5
Schedule 5. adalah sebuah schedule serial dan karena 5% dan 5 ekui7alen dengan 5.,
maka 5% dan 5 adalah serializable schedule.
!ecoverable 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
0da dua teknik concurrency control utama yang mengijinkan transaksi untuk berjalan
dengan aman dalam subjek paralel untuk constraint tertentu, yaitu lockin" dan metode
timestamp tertentu. Lockin" dan timestampin" adalah pendekatan konser7ati/ karena
mereka menyebabkan transaksi ditunda dalam kasus mereka kon/lik dengan transaksi lain
pada beberapa &aktu di masa yang akan datang. Metode optimistik, didasarkan pada
premis bah&a kon/lik itu jarang ditemui, jadi mereka mengijinkan transaksi untuk lanjut
tidak tersinkronisasi dan hanya mengecek kon/lik di bagian akhir, ketika transaksi
melakukan operasi commit.
Metode Loc%in"
Lockin" adalah sebuah prosedur yang digunakan untuk mengendalikan akses bersamaan
ke data. +etika sebuah transaksi sedang mengakses database, sebuah lock mungkin
menolak akses ke transaksi lain untuk mencegah hasil yang salah ( Connolly, !!",
p"8# ). 0da dua macam lock, yaitu shared lock dan e#clusive lock yang harus digunakan
sebelum melakukan akses membaca ataupun menulis terhadap database. Penggunaan
lock ini adalah untuk menjaga konsistensi data didalam database. ;ika sebuah transaksi
mempunyai sebuah shared lock pada sebuah item data, transaksi tersebut dapat membaca
item tapi tidak dapat mengubah datanya ( Connolly, !!", p"88 ). ;ika sebuah transaksi
mempunyai sebuah e#clusive lock pada sebuah item data, transaksi tersebut dapat
membaca dan mengubah item data ( Connolly, !!", p"88 ).
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 e#clusive lock untuk akses membaca dan menulis.
;ika item belum dikunci oleh transaksi lain, lock tersebut akan dikabulkan
;ika item sedang dikunci, )6M5 menentukan apakah permintaan ini compatible
dengan lock saat ini. ;ika diminta shared lock pada sebuah item yang sudah
mempunyai shared lock terpasang padanya, permintaan itu akan dikabulkan.
5elain itu, transaksi harus menunggu sampai lock yang ada terlepas.
5ebuah transaksi lanjut memegang lock sampai transaksi tersebut melepasnya
baik pada &aktu eksekusi ataupun pada &aktu transaksi tersebut berakhir (abort
atau commit). 1/ek operasi tulis akan terlihat pada transaksi lain hanya pada
&aktu e#clusive lock telah dilepas.
$%o &hase Lockin" adalah sebuah transaksi yang mengikuti protokol t%o-phase lockin"
jika semua operasi lockin" mendahului operasi unlock pertama pada transaksi ( Connolly,
!!", p"8* ).
0turan4aturannya adalah sebagai berikut $
5ebuah 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
5ebelum transaksi melepaskan sebuah lock, transaksi tersebut tidak akan pernah
mendapatkan lock baru lainnya.
Deadloc%
Deadlock adalah jalan buntu yang dapat terjadi ketika dua atau lebih transaksi masing4
masing menunggu lock yang sedang dipegang oleh transaksi lainnya untuk dilepas.
=anya ada satu cara untuk menghancurkan deadlock, yaitu abort satu atau lebih
transaksi. 0da tiga cara untuk menangani deadlock, yaitu timeout, deadlock prevention
dan deadlock detection and recovery.
&imeout
Pendekatan sederhana pada pencegahan deadlock adalah berdasarkan lock timeout.
)engan pendekatan ini, sebuah transaksi yang meminta sebuah lock akan menunggu
hanya sampai periode &aktu tertentu yang dide/inisikan sistem.
Deadloc% 'reention
Pendekatan lain untuk mencegah deadlock adalah untuk memesan transaksi
menggunakan timestamp transaksi. )ua algoritma telah ditemukan oleh !osenkrantz.
0lgoritma pertama, 'ait-Die, mengijinkan hanya transaksi yang lebih tua untuk
menunggu yang lebih muda, jika tidak transaksi dibatalkan (die9mati) dan restart dengan
timestamp yang sama, sehingga lama kelamaan transaksi tersebut akan menjadi transaksi
akti/ tertua dan tidak akan mati. 0lgoritma kedua, 'ound-'ait, menggunakan pendekatan
simetrikal. =anya transaksi yang lebih muda yang dapat menunggu untuk yang lebih tua.
;ika transaksi yang lebih tua meminta lock yang dipegang oleh transaksi yang lebih
muda, transaksi yang lebih muda digagalkan.
Deadloc% Detection
Deadlock detection biasanya ditangani oleh konstruksi %ait-(or "raph (>?@) yang
menunjukkan ketergantungan transaksi, yaitu transaksi Ti tergantung pada Tj jika
transaksi Tj memegang lock pada sebuah item data yang ditunggu oleh Ti.
>?@ adalah sebuah directed "raph @ A (-, 1 ) yang terdiri dari satu set node - dan satu
set directed ed"e 1, yang dikonstruksi sebagai berikut
6uat sebuah node untuk setiap transaksi.
6uat sebuah directed ed"e Ti B Tj , jika transaksi Ti menunggu untuk melakukan
lock sebuah item yang sedang di4lock oleh Tj.
Deadlock terjadi jika dan hanya jika >?@ mengandung sebuah cycle. @ambar di atas
menunjukkan >?@ yang menunjukkan deadlock antara dua transaksi.