Anda di halaman 1dari 60

Manajemen Transaksi(3)

Basisi Data: kesadaran akan hilangnya informasi ketika


sistem komputer Anda tiba-tiba macet
.

Pengendalian konkurensi
(concurrency control)
Salah satu karakteristik dasar dari sebuah transaksi
yang harus dipenuhi adalah Isolasi, yang menjamin
tereksekusinya semua transaksi pada sebuah
sistem yang konkuren dengan benar sehingga
konsistensi basis data dapat tetap terpelihara.
Karena itu menjadi sangat penting untuk
mengendalikan interaksi antara transaksi-transaksi
yang sedang bersaing (konkuren), melalui sebuah
mekanisme yang biasa disebut dengan mekanisme
Pengendalian Konkurensi (concurrency control).
Mekanisme ini didasarkan pada prinsip-prinsip
serializability

Lock-Based Protocol(1)
Salah satu cara untuk menjamin serializability
adalah dengan mensyaratkan bahwa akses ke
satuan-satuan data harus dilakukan dengan
menerapkan eksklusivitas. Artinya, selama sebuah
transaksi sedang mengakses sebuah satuan data,
maka tidak ada transaksi lain yang boleh
melakukan perubahan terhadap satuan data
tersebut.
Metode yang umum digunakan untuk menerpakan
hal ini adalah dengan kewajiban melakukan
penguncian pada suatu satuan data sebelum ia
ingin diakses.

Lock-Based Protocol(2)
Ada dua jenis (mode) penguncian dasar yang
digunakan dalam mekanisme ini, yaitu:
Bersama (shared). Jika sebuah transaksi Ti dapat
melakukan penguncian dengan mode ini (dilambangkan
dengan S) terhadap satuan data Q, maka Ti dapat
membaca, tetapi tidak dapat mengubah nilai Q tersebut
Tunggal (exclusive). Jika sebuah transaksi Ti, dapat
melakukan penguncian dengan mode ini (dilambangkan
dengan X) terhadap satuan data Q, maka Ti dapat
membaca maupun mengubah nilai Q tersebut.

Lock-Based Protocol(3)
Pada mekanisme ini ditetapkan bahwa penguncian
dengan mode shared atau S untuk satuan data Q
dapat diberikan kepada sebuah transaksi, jika
satuan data tersebut sedang tidak dikunci oleh
transaksi yang lain, atau paling tidak ia sedang
dikunci dengan mode shared juga oleh transaksi
lainnya.
Jika satuan data tersebut sedang dikunci dengan
mode exclusive, maka hak penguncian kepada
transaksi tersebut tidak dapat diberikan (ditunda
pemberiannya).

Lock-Based Protocol(4)
Jika mode penguncian yang diinginkan oleh sebuah
transaksi adalah exclusive atau X, maka hak
penguncian dengan mode ini hanya akan diberikan
oleh modul concurrency control, jika satuan data
tersebut tidak sedang dikunci dengan mode
apapun.
Tabel ini mencerminkan aturan penguncian, yaitu:

S
X

S
true
false

X
false
false

Lock-Based Protocol(5)
Sebuah transaksi dapat meminta penguncian bahwa mode
shared terhadap satuan data Q dengan menjalankan
perintah lock-S(Q) dan dengan mode exclusive dengan
menjalankan perintah lock-X(Q).
Setelah sebuah transaksi berhasil mendapatkan hak
penguncian terhadap suatu satuan data dan kemudian
selesai melakukan pengaksesan terhadap satuan data
tersebut, maka ia harus segera mungkin melepaskan
pengunciannya, agar transaksi lain yang mungkin juga ingin
mengakses satuan data yang sama pada saat yang hampir
bersamaan tidak lama menunggu untuk mendapatkan hak
penguncian.
Perintah untuk melepaskan hak penguncian adalah
unlock(Q)

Lock-Based Protocol(6)
Dua buah transaksi T1 dan T2. T1 berfungsi untuk
melakukan pentransferan dana dari rekening B ke rekening
A sebesar Rp. 100.000, T1: lock-x (B)
read (B)
B := B 100 000
write (B)
unlock (B)
lock-x (A)
read (A)
A := A + 100 000
write (A)
unlock (A)

Lock-Based Protocol(7)
Sementara transaksi T2 yang hanya berfungsi untuk
menampilkan total saldo dari kedua rekening, A dan B:
T2: lock-s (A)
read (A)
unlock (A)
lock-s (B)
read (B)
write (B)
unlock (B)
display (A + B)

Lock-Based Protocol(8)
Anggaplah saldo awal dari rekening A dan B masing-masing
adalah Rp. 1.000.000,- dan Rp. 2.000.000,-.
Jika kedua transaksi dieksekusi secara serial, baik dengan
urutan <T1, T2> maupun <T2, T1>, maka transaksi T2 akan
menampilkan nilai Rp. 3.000.000, Jika kemudian kedua transaksi dieksekusi secara konkuren
dengan schedule di bawah ini, maka transaksi T2 akan
menampilkan nilai Rp. 2.900.000,- yang tentu saja tidak
benar.
Hal ini terjadi karena transaksi T1 melepaskan penguncian
terhadap satuan data B terlalu cepat, yang kemudian dibaca
oleh transaksi T2 secara tidak konsisten

Lock-Based Protocol(9)
T1

T2

lock-x (B)
read (B)
B := B 100 000
write (B)
unlock (B)

lock-s (A)

lock-x (A)
read (A)
A := A + 100 000
write (A)
unlock (A)

read (A)
unlock (A)
lock-s (B)
read (B)
write (B)
unlock (B)
display (A + B))

Lock-Based Protocol(10)
Karena schedule konkuren tersebut menghasilkan informasi
yang tidak akurat, maka katakanlah kita melakukan
perubahan pada letak perintah pelepasan penguncian
(unlock) dengan menundanya hingga akhir transaksi,
menjadi transaksi T3 dan T4 sebagai berikut:
T3: lock-x (B)
read (B)
B := B 100 000
write (B)
lock-x (A)
read (A)
A := A + 100 000
write (A)
unlock (B)
unlock (A)

Lock-Based Protocol(11)
T4: lock-s (A)
read (A)
lock-s (B)
read (B)
write (B)
unlock (A)
unlock (B)
display (A + B)

Selanjutnya jika kedua transaksi tersebut dieksekusi secara konkuren,


dengan potongan schedule sebagai beriut:

Lock-Based Protocol(12)
T3

T4

lock-x (B)
read (B)
B := B 100 000
write (B)

lock-s (A)
lock-x (A)

read (A)
lock-s (B)

Lock-Based Protocol(13)

Secara teoritis, Schedule ini memberikan hasil yang akurat


sesuai dengan hasil yang diberikan oleh schedule serial. Akan
tetapi, secara praktis, schedule tersebut tidak dapat
dilaksanakan dengan tuntas, karena mengalami kondisi
deadlock.
Kondisi ini terjadi ketika kedua transaksi berada dalam
keadaan saling menunggu, sehingga kedua transaksi tidak
akan pernah selesai dieksekusi.
Jika kita perhatikan transaksi T3, perintah lock-X(B) akan
membuat satuan data B dikunci secara exclusive oleh
transaksi tersebut.
Sementara itu, transaksi T4 mengawali aksi-aksinya dengan
melakukan penguncian terhadap satuan data A.
Ketika transaksi T3 telah menjalankan operasi write(B) dan
kemudian menjalankan perintah lock-X(A), penguncian satuan
data A secara exclusive menjadi tertunda (yang juga menunda
aksi-aksi berikutnya dalam transaksi T3, karena satuan data A
tersebut sedang dikunci oleh transaksi T4.

Lock-Based Protocol(14)
Sementara itu, transaksi T4 yang telah menjalankan operasi
read(A) dan bersiap melakukan penguncian terhadap satuan
data B dengan perintah lock-S(B) juga tidak dapat diteruskan,
karena pada saat yang sama satuan data tersebut telah
dikunci oleh transaksi T3.
Kondisi yang saling menunggu inilah yang biasa dikenal
dengan istilah deadlock yang tidak dapat diatasi dengan baik
oleh DBMS.

Lock-Based Protocol(15)
Jika operasi-operasi dari beberapa transaksi dilakukan tanpa
penerapan penguncian atau jika pelepasan penguncian
dilakukan terlalu cepat, kita akan dapat mengalami
ketidakakuratan/ketidakkonsistenan informasi.
Sementara jika aksi pelepasan penguncian dilakukan di akhir
transaksi, maka kondisi deadlock akan mudah terjadi.
Ini merupakan keadaan dilematis yang memang biasa
dihadapi dalam sebuah sistem konkuren yang memanfaatkan
mekanisme penguncian (locking)

Lock-Based Protocol(16)
Kita akan menetapkan bahwa setiap transaksi yang terlibat
dalam sebuah sistem harus mengikuti sekumpulan aturan
yang disebut Aturan Penguncian (locking protocol), yang
menunjukkan kapan sebuah transaksi boleh dikunci dan
kapan melepaskan penguncian terhadap setiap satuan data
Locking protocol kelak akan dapat menentukan scheduleschedule mana saja yang boleh dipilih
Pada dasarnya mekanisme locking protocol ini hanya akan
membolehkan schedule-schedule yang bersifat conflictserializable.

Pemberian Locking(1)
Ketika sebuah transaksi meminta penguncian pada sebuah satuan
data dengan mode tertentu (A), dan saat itu tidak ada transaksi
lainnya yang melakukan penguncian terhadap satuan data yang
sama dalam mode yang memiliki konflik dengan mode A, maka
penguncian tersebut dapat diberikan. Akan tetapi, harus pula
dicermati terjadinya kondisi berikut ini.
Anggaplah sebuah transaksi T1 mendapatkan hak penguncian
dengan mode shared terhadap sebuah satuan data, dan pada saat
yang sama transaksi lainnya T2 menginginkan penguncian dengan
mode exclusive terhadap satuan data yang sama. Jelas sekali, T2
harus menunggu hingga T1 melepaskan pengunciannya.
Sementara itu, sebuah transaksi lain T3 juga menginginkan
penguncian dengan mode shared terhadap satuan data yang sama.
Karena mode ini kompatibel (cocok) dengan mode penguncian yang
diterapkan oleh transaksi T1, maka kepada T3 dapat segera
diberikan kesempatan untuk juga melakukan penguncian dengan
mode tersebut.

Pemberian Locking(2)
Pada selang waktu tertentu transaksi T1 melepaskan
pengunciannya, akan tetapi datang lagi transaksi lainnya, katakanlah
T4, yang juga ingin melakukan penguncian dengan mode shared di
saat T3 masih belum melepaskan pengunciannya. Sehingga
kemudian T4 dibolehkan untuk melakukan penguncian.

Hal ini dapat berlangsung terus, tetapi akan mengakibatkan


transaksi T2 yang sedari awal dalam kondisi menunggu
melakukan penguncian tetap tidak dapat mendapatkan hak
untuk melakukan penguncian terhadap satuan data tersebut.
Jadi, tidak ada kemajuan bagi transaksi T2. kondisi ini disebut
starvasion.

Pemberian Locking(3)
Untuk menghindari kondisi starvasion ini, maka ketika sebuah
transaksi Ti menginginkan penguncian terhadap satuan data Q
dalam mode tertentu (misalnya mode A), maka hak penguncian
tersebut baru akan diberikan apabila:
Tidak ada transaksi lain yang sedang melakukan
penguncian terhadap satuan data Q dengan mode yang
memiliki konflik dengan mode A
Tidak ada transaksi lain yang sedang menunggu untuk
mendapatkan penguncian terhadap satuan data Q yang
telah lebih dahulu mengajukan permintaan penguncian
tersebut.

Locking Protokol Dua Fase(1)


Protokol ini menginginkan bahwa setiap transaksi yang akan
menjalankan penguncian dan melepaskan penguncian harus
melalui 2 fase atau tahapan, yaitu:
Fase pertumbuhan (Growing Phase). Sebuah transaksi dapat melakukan
sejumlah penguncian, tetapi belum melepaskan satu pun pengunciannya
Fase pelepasan (Shrinking Phase). Sebuah transaksi dapat melepaskan
sejumlah penguncian, tetapi belum melakukan penguncian yang baru
Pada awalnya, sebuah transaksi akan berada dalam fase

pertumbuhan. Transaksi tersebut akan melakukan penguncian


sebanyak yang dibutuhkan nya.
Ketika transaksi mulai melepaskan sebuah penguncian, ia
mulai memasuki fase pelepasan, tanpa ada permintaan
penguncian berikutnya

Locking Protokol Dua Fase(2)


Sebagai contoh, transaksi T3 dan T4 di pembahasan
sebelumnya merupakan transaksi dua fase. Dilain pihak,
transaksi T1 dan T2 bukanlah transaksi dua fase.
Ingat bahwa instruksi unlock tidak perlu muncul di akhir
transaksi. Dalam kasus transaksi T3, kita dapat memindahkan
instruksi unlock(B) persis setelah instruksi lock-X(A), dan tetap
berada dalam kondisi penguncian dua fase.
Locking protokol dua fase menjamin adanya conflict
serializability
Titik dalam schedule dimana transaksi tersebut telah
mendapatkan penguncian akhir (di akhir fase pertumbuhan)
disebut titik penguncian (lock point) transaksi. Sekarang,
transaksi-transaksi dapat diurutkan berdasarkan titik
penguncian mereka. Penguncian ini, secara nyata,
menunjukkan sifat serializability dalam pengeksekusian seluruh
transaksi.

Locking Protokol Dua Fase(3)


Locking protokol dua fase tidak dapat menjamin tidak terjadinya
kondisi deadlock.
Dapat dilihat bahwa transaksi T3 dan T4 merupakan transaksi
dua fase, tetapi seperti yang terlihat pada schedule 2, ternyata
juga mengalami kondisi deadlock.
Terdapat beberapa varian dari mekanisme locking protocol dua
fase ini:
Locking protocol dua fase yang ketat (strict two-phase locking protocol).
Dengan mekanisme ini, juga dikehendaki bahwa semua penguncian
dengan mode exclusive dari sebuah transaksi harus tetap dipegang
hingga transaksi berada dalam status Berhasil sempurna (Commited).
Setiap data yang ditulis oleh transaksi yang belum berstatus commited
terus dikunci dalam mode exclusive, untuk mencegah transaksi lainnya
melakukan pembacaan terhadap satuan data tersebut.
Locking protocol dua fase yang padat (rigorous two-phase locking
protocol), yang menghendaki semua penguncian (baik yang mode
exclusive maupun shared) tetap diterapkan hingga transaksi berstatus
berhasil sempurna (commited). Mudah diperksa, bahwa dengan
mekanisme ini, transaksi-transaksi dapat dikerjakan secara serial sesuai
urutan yang ditunjukkan oleh perintah commit.

Locking Protokol Dua Fase(4)


Pertimbangkan kedua transaksi berikut ini yang hanya
menampilkan operasi read dan write yang relevan.
T5: read (a1)
read (a2)
.
read (an)
write (a1)

T6: read (a1)


read (a2)
write (a1 + a2)

Locking Protokol Dua Fase(5)


Jika kita menerapkan locking protocol dua fase, maka T5
harus mengunci a1 dalam mode exclusive. Karena itu,
semua eksekusi konkuren dari kedua transaksi akan
menjadi eksekusi serial.
Akan tetapi, T5 sebenarnya hanya membutuhkan
penguncian dengan mode exclusive di akhir transaksi di saat
penulisan a1 akan dilakukan.
Karena itu, jika pada awalnya T5 menerapkan mode shared
dalam pengunciannya, dan kemudian menjelang akhir
transaksi mode tersebut diubah menjadi exclusive, kita akan
mendapatkan kondisi konkurensi yang lebih baik, karena T5
dan T6 dapat mengakses a1 dan a2 secara simultan

Locking Protokol Dua Fase(6)


Pengamatan ini membawa kita pada upaya perbaikan dari
mekanisme Locking protocol dua fase, dimana upaya
konversi mode penguncian dimungkinkan.
Kita akan menerapkan langkah peningkatan mode
penguncian dari shared menjadi exclusive, dan penurunan
mode penguncian dari exclusive menjadi shared.
Operasi untuk peningkatan mode tersebut disebut upgrade
dan operasi sebaliknya sebagai downgrade.
Peningkatan mode ini hanya akan berlaku pada fase
pertumbuhan, sementara penurunan mode akan berlaku
pada fase pelepasan.

Locking Protokol Dua Fase(7)


Contoh, transaksi T5 dan T6 dapat dieksekusi secara
konkuren dengan mekanisme locking protocol dua fase
yang telah diperbaiki, sebagaimana yang ditunjukkan pada
schedule yang tidak lengkap berikut ini:
T5

T6

lock-s (a1)
lock-s (a1)
lock-s (a2)
lock-s (a2)
lock-s (a3)
lock-s (a4)

unlock (a1)
unlock (a2)
lock-s (an)
upgrade (a1)

Timestamp-Based Protocol
Dalam mekanisme locking protocol yang telah dibahas
sebelumnya, urutan diantara setiap pasang transaksi yang
memiliki konflik ditentukan pada saat eksekusi oleh
penguncian pertama yang diminta kedua transaksi dengan
mode yang tidak kompatibel
Metode yang lain yang dapat digunakan untuk menentukan
urutan serializability adalah dengan memilih urutan transaksi
sebelumnya.
Metode yang paling populer untuk itu adalah skema
timestamp-ordering.

Timestamp (1)
Skema ini menjamin serializability dengan memilih sebuah
urutan di antara setiap pasangan transaksi. Untuk setiap
transaksi Ti di dalam sistem, ditetapkan sebuah nilai
berdasarkan waktu (semacam tera waktu atau timestamp)
yang tetap dan unik dengan notasi TS(Ti).
Timestamp ini ditentukan oleh DBMS sebelum transaksi Ti
mulai dikerjakan.
Jika sebuah transaksi Ti telah diberi timestamp TS(Ti) dan
kemudian datang transaksi baru Tj, maka TS(Ti) < TS(Tj).

Timestamp (2)
Ada dua metode sederhana untuk menerapkan skema ini:
Memanfaatkan jam komputer (system lock) sebagai
timestamp, sehingga timestamp transaksi akan sama
dengan nilai yang ditunjukkan jam komputer ketika
transaksi tersebut memasuki sistem
Memanfaatkan sebuah penghitungan lojik (logical
counter) yang terus bertambah nilainya begitu nilai
terakhir (current value)-nya diberikan pada sebuah
transaksi baru, sehingga timestamp transaksi akan sama
dengan nilai penghitungan(counter) di saat transaksi
tersebut memasuki sistem

Timestamp (3)
Timestamp-timestamp transaksi tadi akan menentukan
urutan dari serializability-nya. Karena itu, jika timestamp
transaksi Ti lebih kecil daripada timestamp transaksi Tj
(TS(Ti) < TS(Tj)), maka skema ini menjamin bahwa schedule
yang dihasilkan sama dengan schedule serial dimana
transaksi Ti selalu dilaksanakan sebelum transaksi Tj.
Untuk menerapkan skema ini, kita menerapkan dua nilai
timestamp pada setiap satuan data Q:
W-timestamp(Q) yang menunjukkan nilai timestamp terbesar dari
setiap transaksi yang berhasil menjalankan operasi wite(Q)
R-timestamp(Q) yang menunjukkan nilai timestamp terbesar dari
setiap transaksi yang berhasil menjalankan operasi read(Q).

timestamp ini akan terus diperbaharui ketika ada perintah


baru read(Q) atau write(Q) yang dieksekusi.

Timestamp-ordering Protocol (1)


Protokol Timestamp-ordering menjamin bahwa setiap
operasi read dan write yang memiliki konflik dieksekusi
sesuai urutan timestamp.
Protokol ini beroperasi mengikuti aturan berikut ini:
Untuk transaksi Ti yang menjalankan operasi read(Q)
Jika TS(Ti) < w-timestamp(Q), maka Ti perlu membaca kembali nilai Q yang telah
ditulis. Karena itu, operasi read ini akan ditolak dan Ti akan dibatalkan (di
rollback).
Jika TS(Ti) w-timstamp(Q), maka operasi read dieksekusi, dan R-timestamp(Q)
diisi dengan nilai terbesar di antara TS(Ti) dan R-timestamp(Q)

Untuk transaksi Ti yang menjalankan operasi write(Q)


Jika TS(Ti) < R-timestamp(Q), maka nilai Q yang baru dihasilkan Ti adalah nilai
yang tidak akan dimanfaatkan lagi, dan sistem berasumsi bahwa nilai tersebut
tidak pernah dihasilkan. Karena itu, operasi write ditolak dan transaksi Ti
dibatalkan (di rollback)
Jika TS(Ti) < w-timestamp(Q), maka itu berarti TI sedang berusaha melakukan
penulisan nilai Q yang kadaluarsa. Karena itu, operasi write ini akan ditolak dan
Ti akan dibatalkan (di rollback)
Diluar kondisi a dan b di atas, operasi write dieksekusi, dan W-timestamo(Q)
diberi nilai yang sama dengan TS(Ti).

Timestamp-ordering Protocol (2)


Terhadap transaksi Ti, yang dibatalkan (di-rollback) oleh
mekanisme concurrency-control di atas sebagai hasil dari
penggunaan operasi read dan write, akan diberikan sebuah
nilai timestamp yang baru dan diulang kembali
Untuk menggambarkan protokol ini, kita mempertibangkan
transaksi T7 dan T8. Transaksi T7 menampilkan nilai saldo
rekening A dan B dan didefinisikan sebagai:
T7:

read (B)
read (A)
display (A + B)

Timestamp-ordering Protocol (3)


Transaksi T8 yang mentransfer dari rekening A ke rekening
B dan kemudian menampilkan isi keduanya:
T8:

read (B)
B = B 100 000
write (B)
read (A)
A := A + 100 000
write (A)
display (A + B)

Timestamp-ordering Protocol (4)


Dalam menentukan schedule dengan protokol timestamp,
kita mengasumsikan bahwa sebuah transaksi diberikan
sebuah timestamp dengan segera sebelum instruksi
pertama. Karena itu, dalam schedule berikut ini, TS(T7) <
TS(T8) dan schedule ini mungkin dieksekusi dengan
menggunakan protokol timestamp-ordering.
T7

T8

read (B)
read (B)
B := B - 100000
write (B)
read (A)
read (A)

lock-s (A)
A := A + 100000
write (A)
display (A + B)

Timestamp-ordering Protocol (5)


Eksekusi awal dapat juga dihasilkan oleh locking protokol
dua fase. Akan tetapi, ada schedule yang diperbolehkan
dalam locking protokol dua fase tetapi tidak berlaku dalam
timestamp protocol, dan sebaliknya
Protokol timestamp-ordering menjamin conflict serializability.
Pernyataan ini berasal dari fakta bahwa operasi-operasi
yang memiliki konflik satu sama lain diproses dalam urutan
timestamp-nya.
Dengan protokol ini, sistem konkuren terbebas dari kondisi
deadlock, karena tidak ada transaksi yang harus menunggu.

Validation-based Protocol (1)


Dalam kasus dimana sebagian besar transaksi merupakan
transaksi yang read-only (didominasi oleh instruksi
pembacaan data), tingkat konflik di antara transaksitransaksi menjadi rendah. Karena itu, walaupun transaksitransaksi ini dieksekusi tanpa pengawasan skema
concurrency control, konsistensi sistem tidak akan
terpengaruh/terganggu.
Padahal, penerapan skema concurrency control, akan
mengakibatkan bertambahnya proses/program yang harus
dikerjakan dan berpeluang menunda pelaksanaan transaksi
menjadi lebih lama
Karenanya, sangat logis untuk menggunakan skema
alternatif lain yang waktu tambahan (overhead)-nya bisa
lebih kecil, yakni dengan meminimalkanpenerapan skema
concurrency control tersebut

Validation-based Protocol (2)


Dengan asumsi setiap transaksi Ti dieksekusi dalam dua
atau tiga fase berbeda selama masih berlangsung pada
apakah transaksi tersebut hanya melakukan pembacaan
data atau melakukan perubahan data.
Ketiga fase tersebut adalah:
Fase pembacaan. Selama fase ini, eksekusi transaksi Ti akan
dijalankan. Nilai dari berbagai satuan data dibaca dan kemudian
disimpan ke dalam variabel-variabel lokal untuk Ti. Semua operasi
write dilakukan terhadap variabel lokal temporer, tanpa perubahan ke
basis data yang aktual
Fase validasi. Transaksi Ti membentuk uji validasi untuk menentukan
apakah transaksi tersebut dapat melakukan penyalinan/pengubahan
ke basis data dari variabel-variabel lokal temporer yang nilai-nilainya
diperoleh dari operasi-operasi write tanpa menyebabkan pelanggaran
serializability
Fase penulisan. Jika fase validasi untuk transaksi Ti dalam langkah
kedua di atas berhasil, maka perubahan sesungguhnya dilakukan ke
basis data. Jika fase validasi ini tidak berhasil, mka Ti akan
dibatalkan (di rollback)

Validation-based Protocol (3)


Setiap transaksi harus dijalankan melalui ketiga fase dengan
urutan seperti yang dijelaskan sebelumnya.akan tetapi,
semua fase dalam pengeksekusian transaksi secara
konkuren dapat terjadi pada waktu yang bersamaan.
Fase pembacaan dan fase penulisan sudah cukup jelas.
Fase yang harus ditelaah lebih jauh adalah fase validasi.
Untuk melakukan uji validasi, kita perlu mengetahui berbagai
fase transaksi Ti yang sedang berlangsung. Kita akan
mengasosiasikan tiga buah timestamp berbeda terhadap
transaksi Ti, sebagai berikut:
Start(Ti), waktu dimana Ti memulai eksekusinya
Validation(Ti), waktu dimana Ti selesai melakukan fase pembacaan
dan memulai fase validasi
Finish(Ti), waktu dimana Ti menyelesaikan fase penulisan

Validation-based Protocol (4)


Dalam menentukan urutan serializability dengan teknik
timestamp-ordering dengan menggunakan nilai timestamp
validation(Ti). Karena itu, nilai TS(Ti)= validation(Ti).
Jika misalnya ada transaksi lain, Tj dan Tk, dan jika TS(Tj) <
TS(Tk), maka setiap schedule yang dihasilkan harus
ekuivalen dengan schedule serial dimana transaksi Tj
muncul sebelum Tk
Alasan memilih validation(Ti) ketimbang Start(Ti) sebagai
timestamp transaksi Ti adalah karena kita dapat
mengharapkan waktu tanggap lebih cepat yang dapat
diberikan, sehingga tingkat konflik di antara transaksitransaksi menjadi lebih kecil

Validation-based Protocol (5)


Uji validasi untuk transaksi Tj mensyaratkan bahwa, untuk
semua transaksi Ti, dengan TS(Ti) < TS(Tj), salah satu dari
dua kondisi berikut harus dapat dipenuhi, yaitu:
Finish(Ti) < Start(Tj). Karena Ti menyelesaikan ekesekusinya
sebelum Tj dimulai, urutan serializability dapat dipelihara
Himpunan satuan data yang ditulis oleh Ti tidak beririsan dengan
himpunan satuan data yang dibaca oleh Tj, dan Ti menyelesaikan
fase penulisan-nya sebelum Tj mulai fase validasinya (Start(Tj) <
Finish(Ti) < Validation(Tj)). Kondisi ini menjamin bahwa operasi
penulisan Ti dan Tj tidak saling bersinggungan. Karena penulisan
dalam Ti, tidak mempengaruhi pembacaan dalam Tj, dan karena Tj
tidak dapat mempengaruhi pembacaan Ti, maka urutan serializability
juga dapat dipelihara

Validation-based Protocol (6)


Lihat transaksi T7 dan T8 sebelumnya. Katakanlah, TS(T7)
< TS(T8).maka fase validasi akan berhasil dalam schedule
berikut ini. Ingatlah bahwa penulisan/perubahan akhir ke
basis data hanya dilakukan setelah fase validasi dari T8.
Karena itu, T7 akan membaca nilai-nilai lama dari rekening
B dan A, dan akhirnya schedule ini bersifat serializable
T7

T8

read (B)
read (B)
B := B - 100000
read (A)
A := A + 100000
read (A)
< validas i>
display (A+B)

< Validasi >


write (B)
write (A)

Validation-based Protocol (7)


Skema validasi ini secara otomatis terlindung dari penjalaran
rollback (dimana semua transaksi di-rollback akibat adanya
sebuah transaksi yang di-rollback pada sebuah pelaksanaan
transaksi yang konkuren), karena penulisan aktual ke basis
data hanya akan dikerjakan setelah transaksi yang
mengandung operasi write telah di-commit

Penanganan Deadlock (1)


Deadlock merupakan kondisi dimana ada lebih dari satu
transaksi berada dalam keadaan menunggu (waiting state)
untuk melakukan akses/perubahan terhadap suatu satuan
data yang rupanya sedang dikunci oleh transaksi lain yang
juga sedang menunggu.
Lebih jauh dikatakan, ada sekumpulan transaksi yang sedang
menunggu (T0, T1,.., Tn) sedemikian hingga T0 menunggu
pemakaian sebua satuan data yang sedang dipegang oleh
T1, dan T1 sedang menunggu pemakaian sebuah satuan
data yang sedang dipegang oleh T2, dst hingga Tn-1 sedang
menunggu pemakaian sebuah satuan data yang sedang
dipegang Tn, dan Tn sedang menunggu pemakaian sebuah
satuan data yang sedang dipegang oleh T0.
Tidak satupun dari transaksi tersebut dapat beranjak dari
situasi tsb. Satu-satunya cara untuk melepaskan diri dari
situasi ini adalah dengan melakukan aksi drastis, seperti
membatalkan sejumlah transaksi yang terlihat dalam kondisi
deadlock tersebut.

Penanganan Deadlock (2)


Ada dua metode dasar untuk mengatasi masalah deadlock
tsb, yaitu:
Pencegahan deadlock (deadlock-prevention) untuk menjamin bahwa
sistem tsb tidak pernah memasuki kondisi deadlock
Pendeteksian dan pemulihan deadlock (deadlock-detection and
deadlock-recovery), kita dapat mengijinkan sistem memasuki kondisi
deadlock, dan kemudian berusaha untuk mengatasinya dengan
memanfaatkan skema pendetksian dan pemulihan deadlock

Kedua metoda ini bisa berdampak pada terjadinya


pembatalan transaksi (rollback). Metode pertama umum
digunakan jika sistem sering mengalami kondisi deadlock,
tapi jika tidak metode kedua akan lebih efisien.
skema deteksi dan pemulihan deadlock akan menyebabkan
tambahan beban (overhead) yang tidak hanya meliputi biaya
waktu eksekusi (run-time) dalam pemeliharaan informasi yang
penting dan eksekusi algoritma pendeteksian, tetapi juga
akibat potensi kehilangan data pada saat proses pemulihan
(recovery) dari kondisi deadlock tersebut

Pencegahan Deadlock (1)


Ada dua pendekatan dalam mencegah terjadinya deadlock.
Pendekatan 1 menjamin bahwa tidak ada siklus penantian yang terjadi
dengan mengantrikan permintaan penguncian, atau dengan
mensyaratkan semua penguncian harus terpenuhi secara bersamaan.
Pendekatan 2 lebih mendekati cara pemulihan deadlock (deadlock
recovery) dan membentuk pembatalan transaksi (rollback) sebagai
ganti penantian penguncian, ketika penantian tersebut potensial
menghasilkan kondisi deadlock.

Skema yang paling sederhana untuk pendekatan 1


mensyaratkan bahwa setiap transaksi mengunci semua
satuan datanya sebelum eksekusi dimulai. Lebih jauh lagi ,
semua satuan data tsb dikunci sekaligus atau tidak sama
sekali.
Ada dua kelemahan dalam protokol ini:
Seringkali sulit untuk memperkirakan satuan data yang mana saja yang
perlu dikenai penguncian, sebelum transaksi dimulai
Pemakaian satuan data bisa menjadi sangat rendah, karena banyak
satuan data yang dikenai penguncian tetapi sebenarnya tidak
digunakan untuk jangka waktu yang lama

Pencegahan Deadlock (2)


Skema yang lain untuk melakukan pencegahan deadlock
adalah dengan memaksakan sebuah pengurutan parsial dari
semua satuan data, dan mengharuskan transaksi melakukan
penguncian ke suatu satuan data hanya dalam urutan yang
ditentukan dalam urutan parsial tadi. Kita dapat melihat hal ini
dalam protokol hirarkis
Pendekatan kedua untuk pencegahan deadlock adalah
dengan menggunakan pemilikan (preemption) yang
dipadukan dengan pembatalan transaksi (rollback).
Dalam proses pemilikan, ketika sebuah transaksi T2 meminta
penguncian pada suatu satuan data yang sedang dipegang
oleh transaksi T1, penguncian yang diberikan pada T1 dapat
dianulir dengan membatalkan (rollback) transaksi T1 untuk
kemudian memberikan hak penguncian pada T2
Untuk mengontrol kepemilikan tsb, kita menerapkan
timestamp yg unik pada setiap transaksi. Sistem
menggunakan timestamp ini hanya untuk memutuskan
apakah sebuah transaksi harus menunggu atau dibatalkan

Pencegahan Deadlock (3)


Mekanisme penguncian tetap digunakan untuk
mengendalikan konkurensi, jika sebuah transaksi dibatalkan,
ia tetap memiliki timestamp lamanya ketika transaksi tsb
dimulai kembali.
Ada dua bentuk skema pencegahan deadlock yang
menggunakan timestamp ini:
Skema wait-die yang didasarkan pada teknik ketiadaan pemilikan (non-preemptive
technique). Ketika transaksi Ti membutuhkan sebuah satuan data yang sedang dipegang
oleh Tj, Ti dibolehkan untuk menunggu hanya jika ia memiliki timestamp yang lebih kecil
dari Tj (jadi Ti lebih dulu ketimbang Tj). Jika tidak, Ti akan dibatalkan (mati). Sebagai
contoh, katakanlah bahwa kita memiliki transaksi T9, T10 dan T11 yang masing-masing
memiliki timestamp 5, 10, dan 15. Jika T9 membutuhkan sebuah satuan data yang
sedang dipegang oleh T10, maka T9 akan menunggu. Jika T11 membutuhkan satuan
data yang sedang dipegang oleh T10, maka T11 akan dibatalkan (rollback)
Skema wound-wait yang didasarkan pada teknik kepemilikan (preemptive technique)
dan merupakan lawan dari skema pertama. Ketika transaksi Ti membutuhkan satuan
data yang sedang dipegang oleh Ti, Ti dibolehkan menunggu hanya jika ia memiliki
timestamp yang lebih besar dari Tj (jadi Ti lebih belakangan ketimbang Tj). Jika tidak, Tj
akan dibatalkan (Tj dianulir oleh Ti). Pada contoh kasus yang sama, yang melibatkan
transaksi T9, T10 dan t11, jika T9 membutuhkan satuan data yang dipegang oleh T10,
maka satuan data tsb akan diambil alih dari T10, dan T10 akan dibatalkan. Jika T11
membutuhkan satuan data yang dipegang T10, maka T11 akan menunggu.

Pencegahan Deadlock (4)


Kapanpun transaksi dibatalkan (roll back), harus pula dihindari
kondisi tidak menguntungkan lainnya yang disebut starvation,
yaitu terjadinya proses pembatalan transaksi (roll back) terus
menerus dan tidak pernah mengalami kemajuan.
Kedua skema diatas (wound-wait dan wait-die) dapat
menghindari terjadinya starvation: pada setiap waktu, ada
sebuah transaksi dengan nilai timestamp terkecil.
Transaksi ini tidak dapat dikenai roll back di kedua skema.
Karena nilai timestamp selalu meningkat, dan karena
transaksi tidak diberi nilai timestamp yang baru ketika ia roll
back, maka transaksi yg di-roll-back tsb suatu saat akan
memiliki nilai timestamp terkecil. Karena itu, tidak akan di-roll
back terus menerus

Pencegahan Deadlock (5)


Perbedaan penting dalam cara beroperasinya kedua skema:
Dalam skema wait-see, transaksi yg lebih dahulu (dengan timestamp
lebih kecil) harus menunggu hingga transaksi yang lebih belakangan
melepaskan pengunciannya terhadap suatu satuan data. Dengan
demikian, semakin tua usia sebuah transaksi, semakin sering ia
mengalami situasi menunggu. Dalam skema wound-wait, transaksi yg
lebih dahulu tidak akan menunggu transaksi yg belakangan.
Dalam skema wait-see, jika sebuah transaksi Ti mati dan dibatalkan
karena ia membutuhkan satuan data yg sedang dipegang oleh Tj,
maka Ti dapat memiliki urutan permintaan yg sama ketika eksekusinya
diulangi. Jika satuan data tsb masih dipegang oleh Tj, maka Ti bisa
dimatikan kembali. Dengan begitu, Ti bisa dimatikan beberapa kali
sebelum mendapatkan satuan data yang dibutuhkannya.
Dalam skema wound-wait, yang terjadi justru sebaliknya. Transaksi Ti
dibatalkan kerena Tj membutuhkan satuan data yg sedang dipegang
oleh Ti. Ketika Ti dimulai kembali dan membutuhkan satuan data yg
sama yg sedang dipegang oleh Tj, maka Ti akan menunggu. Karena
itu, peristiwa roll-back akan lebih sedikit terjadi dalam skema woundwait.

Skema berbasis timeout(1)


Pendekatan sederhana lainnya dalam penanganan deadlock
didasarkan pada pemakaian batas waktu penguncian (lock
timeouts).
Dalam pendekatan ini, sebuah transaksi yg membutuhkan
sebuah penguncian akan menunggu selama batas waktu yg
telah ditentukan,
Jika hak penguncian tidak juga diberikan hingga batas waktu
tsb dilewati, maka transaksi tsb telah mengalami timeout dan
ia telah membatalkan dirinya sendiri dan mengulangi
eksekusinya kembali. Jika ternyata ada kondidi deadlock yg
terjadi, satu atau lebih transaksi yg terlibat dalam kondisi tsb
akan memasuki masa timeout dan membatalkan eksekusinya
sehingga memungkinkan transaksi lainnya untuk meneruskan
prosesnya.

Skema berbasis timeout(2)


Skema timeout ini mudah untuk diterapkan, dan bekerja
dengan baik jika transaksi-transaksi yg terlibat merupakan
transaksi yg pendek dan jika waktu tunggu yg lama mengarah
pada terjadinya deadlock.
Namun demikian, secara umum akan sukar untuk
memutuskan berapa lama sebuah transaksi harus menunggu
sebelum kondisi timeout dicapai.
Jika terlalu lama, masa tunggu yg tidak perlu akan terjadi di
saat kondisi deadlock memang sudah terjadi. Tapi jika terlalu
cepat, transaksi bisa saja dibatalkan (roll back) pada saat
sebenarnya deadlock tidak terjadi, tetapi karena adanya
transaksi yg memang lama eksekusinya
Kondisi starvation juga dapat terjadi dalam skema ini. Dengan
kelemahan-kelemahan tsb, skema berbasis timeout ini jarang
digunakan.

Pendeteksian dan pemulihan


deadlock
Jika sebuah sistem tidak memanfaatkan protokol yg bebas
dari kondisi deadlock, maka skema pendeteksian dan
pemulihan deadlock harus digunakan
Sebuah algoritma yg memonitor keadaan sistem digunakan
secara periodik untuk menentukan apakah deadlock terjadi
atau tidak. Jika memang telah terjadi,maka sistem harus
berusaha memulihkan sistem tsb dari kondisi deadlock tsb
Untuk melakukan hal itu, sistem harus:
Memelihara cukup informasi yg berkaitan dengan alokasi satuan data
yg sedang digunakan transaksi dan juga satuan data yg sedang
dibutuhkan oleh transaksi-transaksi tsb
Menyediakan sebuah algoritma yg menggunakan informasi ini untuk
menentukan apakah sistem telah berada dalam kondisi deadlock atau
tidak
Memulihkan sistem dari kondisi deadlock ketika algoritma tsb dapat
mendeteksi adanya deadlock.

Pendeteksian deadlock (1)


Deadlock dapat digambarkan dengan lebih rinci dengan
memanfaatkan perangkat graph yg disebut graph wait-for.
Graph ini terdiri atas pasangan G = (V,E), dimana V mewakili
sekumpulan simpul dan E mewakili sekumpulan busur.
Sekumpulan simpul terdiri atas semua transaksi di dalam
sistem. Setiap elemen dalam himpunan simpul E merupakan
pasangan Ti Tj, jika Ti Tj ada di dalam E, maka ada
busur berarah dari transaksi Ti ke transaksi Tj yg
menunjukkan bahwa transaksi Ti sedang menunggu transaksi
Tj untuk melepaskan penguncian pada satuan data yang
dibutuhkan Ti.
Ketika transaksi Ti membutuhkan satuan data yg sedang
dipegang oleh transaksi Tj, maka busur Ti Tj ditambahkan
ke dalam graph wait-for. Busur ini akan dihapuskan hanya
ketika transaksi Tj telah melepaskan satuan data yang
dipegangnya yg dibutuhkan oleh Ti

Pendeteksian deadlock (2)


Sebuah deadlock akan terjadi di dalam sistem jika dan hanya
jika, dalam graph wait-for tsb terdapat sebuah siklus. Setiap
transaksi yg terlibat dalam sebuah siklus dikatakan terkena
deadlock.
Untuk mendeteksi deadlock, sistem perlu mengelola graph ini
dan secara periodik menjalankan algoritma untuk memeriksa
ada tidaknya siklus di dalam graph tersebut.
Untuk mengilustrasikan konsep ini, perhatikan graph berikut
ini yg menunjukkan situasi:
Transaksi T12 yg sedang menunggu transaksi T13 dan T14
Transaksi T14 yg sedang menunggu transaksi T13
Transaksi T13 yg sedang menunggu transaksi T15
T13

T12

T14

T15

Pendeteksian deadlock (3)


Karena graph di atas tidak memiliki siklus, maka sistem tidak
berada dalam kondisi deadlock.
Anggaplah sekarang transaksi T15 membutuhkan satuan data
yg sedang dipegang oleh T14. busur T15 T14 ditambahkan
pada graph di atas, menghasilkan sebuah kondisi sistem yang
baru berikut ini

T13

T15

T12

T14

Maka pada saat ini, graph mengandung sebuah siklus T13 T15 T14
T13 yang mengakibatkan transaksi T13, T14, dan T15 mengalami
kondisi deadlock

Pendeteksian deadlock (4)


Untuk itu, muncul pula pertanyaan tentang kapan kita harus
menjalankan algoritma untuk pendeteksian kondisi deadlock
tersebut? Jawaban atas pertanyaan ini tergantung pada
kedua faktor berikut ini:
Seberapa sering sebuah deadlock terjadi
Seberapa banyak transaksi yg terkena dampak atas terjadinya
deadlock
Jika deadlock sering terjadi, maka algoritma pendeteksian deadlock harus
juga lebih sering diaktifkan. Satuan-satuan data yg dialokasikan untuk
transaksi-transaksi yg mengalami deadlock tidak akan diperoleh oleh
transaksi lain hingga kondisi deadlock tsb diatasi.
Selanjutnya, jumlah siklus dalam graph tersebut bisa saja bertambah.
Dalam kondisi terburutk, maka kita dapat mengaktifkan algoritma
pendeteksian deadlock ini setiap kali sebuah permintaan pengalokasian
data tidak dapat dipenuhi dengan segera.

Pemulihan dari deadlock (1)


Ketika algoritma pendeteksian deadlock dapat mengetahui
terjadinya deadlock, sistem harus melakukan langkah
pemulihan (recovery). Solusi yg paling umum adalah dengan
menjalankan proses roll back pada satu atau beberapa
transaksi untuk lepas dari kondisi deadlock.
Ada tiga aksi yg harus dilakukan:
Pemilihan korban. Pada sekumpulan transaksi yg mengalami deadlock,
kita harus menentukan transaksi mana saja yg akan dibatalkan (di-roll
back). Kita harus me-roll back transaksi dengan ongkos yg minimum.
Sayangnya, kriteria minimum di sini juga sukar ditentukan. Banyak
faktor yg dapat menentukan ongkos yg harus dibayar jika dilakukan roll
back, seperti:
Berapa lama transaksi-transaksi tsb telah dihitung, dan berapa lama lagi transaksi
tsb akan diproses hingga selesai.
Berapa banyak satuan data yg digunakan transaksi tsb
Berapa banyak satuan data lagi yg diperlukan transaksi tsb hingga selesai
Berapa banyak transaksi yg akan terlibat dalam proses roll back tsb

Pemulihan dari deadlock (2)


Roll back. Setiap kali kita telah memutuskan bahwa transaksi tertentu
harus di-roll back, kita harus menentukan pula sejauh mana transaksi
ini harus di-roll back. Cara yg paling sederhana adalah dengan
menjalankan total roll back. Namun demikian, akan lebih efektif untuk
menjalankan proses roll back hanya sejauh yg diperlukan untuk keluar
dari kondisi deadlock. Tetapi metode ini membutuhkan pengelolaan
tambahan informasi tentang status semua transaksi yang sedang aktif.
Starvation. Dalam sebuah sistem dimana pemilihan korban didasarkan
pada faktor-faktor biaya, bisa terjadi sebuah transaksi selalu dipilih
sebagai korban yg akan dikenai proses deadlock. Akibatnya transaksi
tsb tidak pernah bisa selesai. Situasi ini disebut dengan starvation. Kita
harus menjamin bahwa transaksi dapat dipilih sebagai korban hanya
dalam jangan waktu terbatas. Cara yg paling umum ditempuh adalah
dengan melibatkan pula jumlah proses roll back yg dialami sebuah
transaksi sebagai faktor biaya