concurrency control

Anggota Kelompok :
Theodorin Hanna V.K (115314020)
Nur Indani Sari
(115314023)
Pandu Wibowo
(115314025)
Bimo Santoso Aji
(115314026)
Transaksi
• Suatu tindakan, atau serangkaian tindakan yang
dilakukan oleh single user atau program aplikasi,
dengan membaca atau memperbarui isi
database.
• Sebuah unit logis yang bekerja pada database.
Mungkin seluruh program,bagian dari program,
biasanya berupa perintah tunggal (misalnya,
perintah SQL INSERT atau UPDATE), dan mungkin
melibatkan sejumlah operasi pada database.
Transaksi
“Sebuah unit eksekusi program yang mengakses
dan mengubah beberapa item data dalam Database”
• Dalam konteks BD, pelaksanaan suatu
program aplikasi bisa dianggap sebagai satu
atau lebih transaksi dengan non-database
pengolahan yang ada.
• Untuk menggambarkan konsep transaksi, kita
lihat contoh dua relasi dari DreamHome rental
database yang ditampilkan pada Gambar
berikut ini:
• Sebuah transaksi sederhana yg
terjadi pd
database ini adalah untuk memperbarui gaji Staf
yang definisikan sebagai x. Pada tingkat tinggi,
kita bisa menuliskan transaksi ini seperti yang
ditunjukkan pada Gambar 20.1 (a).
• Dalam gambar ini kita ditunjukkan database yang
membaca atau menulis operasi pada data barang
yang diinisialkan dengan x sebagai read (x) atau
write (x).
• Dalam contoh ini, kita memiliki transaksi yang
terdiri dari dua operasi database (membaca
dan menampilkan) dan sebuah operasi nondatabase
Contohnya (gaji = gaji * 1.1).
• Ada lagi transaksi yang lebih rumit, yakni
transaksi untuk menghapus staf dengan staf
yang diidentifikasi sebagai x, seperti yang
ditunjukkan pada Gambar 20.1 (b).
• Dalam kasus ini sebaik mungkin kita harus
menghapus tuple dalam relasi staff, kita juga
harus menemukan semua tuple PropertyForRent
yang dikelola staff mengalihkannya kestaf yang
berbeda, yaitu newStaffNo.
• Jika semua update-an tidak dibuat maka,
semua informasi yg dibutuhkan di DB akan
hilang dan database menjadi tidak konsisten.
properti akan dikelola oleh anggota staff yang
tidak lagi ada dalam database.
• Sebuah transaksi harus selalu mengubah
database dari satu kondisi ke kondisi konsisten
lain,
walaupun transaksi itu menerima konsistensi
yang mungkin dilanggar ketika transaksi
sedang berlangsung.
• Sebagai contoh, selama transaksi pada Gambar
20.1 (b), mungkin ada saat tertentu ketika salah
satu tuple PropertyForRent berisi nilai
newStaffNo baru dan yg lain masih mengandung
yang lama, yakni x.
• Tapi pada akhir transaksi, semua tuple yang
diperlukan harus punya newStaffNo nilai.
• jika transaksi tidak berhasi dieksekusi, else nya
transaksi akan dibatalkan.
• Jika transaksi dibatalkan, database harus
dikembalikan ke keadaan awal sebelum
transaksi dimulai. Bagai transaksi yang terguling
kembali atau traksaksi yang dibatalkan.
Dan transaksi yang sudah di commit gak bisa
dikembalikan lagi.
• Jika kita memutuskan bahwa traksaksi yang udah
di commit salah, kita harus melakukan transaksi
lain yang serupa untuk membalikkan efek.
• (seperti yang kita bahas dalam Bagian
20.4.2).
• DBMS tidak memiliki cara pasti untuk
mengetahui update-an untuk membentuk
transaksi logis tunggal, karena harus
menyediakan metode yg memungkinkan
pengguna untuk menunjukkan batas-batas
transaksi yang dilalukan.
TRANSAKSI BERDASARKAN SIFAT DATA
• Partially Commited
Pada titik ini dapat ditemukan bahwa transaksi
telah melanggar serializability
(lihat Bagian 20.2.2) atau telah melanggar
suatu kendala keutuhan data dan efeknya
transaksi harus dibatalkan.
• Failed
terjadi jika transaksi tidak dapat dilakukan
atau transaksi dibatalkan, mungkin karena
pengguna membatalkan transaksi untuk
memastikan serializability.
Dalam Konsep transaksi di database harus di penuhi
empat sifat database agar integritas database tetap
terjaga. Adapun keempat sifat tersebut adalah :
• Atomicity: Setiap transaksi harus dijamin untuk dapat
sukses dalam melakukan aksinya atau jika gagal , maka
tidak berpengaruh apapun terhadap database.
• Consistency: Setiap transaksi adalah sebuah aksi
kombinasi secara logikal dari sebuah state database
yang konsisten ke state yang lain dengan tetap menjaga
kekonsisten-an database tersebut.
• Isolation: Meskipun ada beberapa transaksi yang
berlangsung bersamaan, masing-masing transaksi tidak
boleh mengetahui transaksi lain yang sedang
berlangsung. Hasil transaksi sementara harus
disembunyikan dari transaksi lain yang sedang
berlangsung . (level transparansi transaksi dapat di set).
• Durability: Setelah sebuah transaksi sukses dilakukan,
perubahan-perubahan yang dibuatnya terhadap
database bersifat permanen, bahkan jika terjadi
kegagalan sistem sekalipun.
Database
Arsitektur
Concurrency Control
• Salah
satu
tujuan
utama
dalam
mengembangkan database adalah untuk
memungkinkan banyak pengguna mengakses
data yang sama secara bersamaan.
Concurrency Control
• Akses bersamaan akan menjadi lebih mudah jika
semua pengguna hanya dapat membaca data
saja. Dengan demikian tidak akan memberikan
kesempatan kepada pihak tertentu untuk
‘mengganggu’ orang lain.
Concurrency Control
• Gangguan akan terjadi jika dua atau lebih user
mengakses database secara simultan dan
sedikitnya melakukan suatu perubahan
(update), maka dapat menyebabkan data
tidak konsisten.
Concurrency Control
• Terdapat tiga masalah potensial yang disebabkan
oleh concurrency, yaitu:
1. Masalah kehilangan modifikasi (Lost
Updates Problem)
2. Masalah ketergantungan yang tidak terikat
(Uncommitted Dependency Problem)
3. Masalah analisa yang tidak konsisten
(Inconsistent Analysis Problem)
Masalah Kehilangan Modifikasi
(Lost Updates Problem)
• Masalah ini timbul jika dua transaksi
mengakses item database yang sama
yang mengakibatkan nilai dari
database tersebut menjadi tidak
benar.
Masalah Kehilangan Modifikasi
(Lost Updates Problem)
TRANSAKSI A
WAKTU
TRANSAKSI B
=
Baca R
=
=
=
Modifikasi R
=
=
=
↓
t1
↓
t2
↓
t3
↓
T4
↓
=
=
=
Baca R
=
=
=
Modifikasi R
=
Transaksi A membaca data pada waktu T1. Dalam proses membacanya, di waktu
T2, Transaksi B juga melakukan proses pembacaan. Kemudian oleh Transaksi A,
dilakukan modifikasi saat waktu T3 dimana Transaksi B sedang dalam proses
membaca. Dan pada waktu T4, Transaksi B melakukan modifikasi dimana pada
Transaksi A sudah selesai. Maka hasil modifikasi oleh Transaksi A dan Transaksi B
akan hilang karena dilakukan saat data di proses secara bersamaan.
Masalah Modifikasi Sementara
(Uncommitted Dependency Problem)
• Masalah ini timbul jika transaksi membaca
suatu record yang sudah dimodifikasi oleh
transaksi lain tetapi belum terselesaikan
(uncommited), terdapat kemungkinan kalau
transaksi tersebut dibatalkan (rollback).
Masalah Modifikasi Sementara
(Uncommitted Dependency Problem)
Nilai saldo menjadi tidak benar disebabkan terjadi RollBack pada
T7 yang membatalkan transaksi sebelumnya (T6), sehingga saldo
seharusnya tetap 2.000.000
Masalah Modifikasi Sementara
(Uncommitted Dependency Problem)
• Transaksi membaca nilai yang ditulis oleh
transaksi yang telah kemudian dibatalkan.
Nilai ini menghilang dari database pada abort,
dan tidak seharusnya dibaca oleh setiap
transaksi ("membaca kotor"). Pembacaan
transaksi diakhiri dengan hasil yang salah.
• Kedua masalah dalam contoh ini berkonsentrasi
pada transaksi yang memperbarui database dan
gangguan mereka dapat merusak database.
• Namun, transaksi yang hanya membaca database
juga dapat menghasilkan hasil yang tidak akurat
jika mereka diizinkan untuk membaca hasil
parsial dari transaksi yang tidak lengkap yang
bersamaan memperbarui database.
Masalah Analisa yang Tidak Konsisten
(Inconsistent Analysis Problem)
• Masalah ini timbul jika sebuah transaksi
membaca suatu nilai tetapi transaksi yang
kedua mengupdate beberapa nilai tersebut
selama eksekusi transaksi pertama
Masalah Analisa yang Tidak Konsisten
(Inconsistent Analysis Problem)
Contoh transaksi T6 menjumlahkan variable balx
(£100), baly (£50), dan balz (£25). Pada saat yang
hampir bersamaan transaksi T5 memindahkan £10 dari
balx ke balz, sehingga transaksi T6 mendapatkan hasil
akhir yang salah (yaitu kelebihan £10).
Masalah tersebut dapat dihindari dengan mencegah
transaksi T6 membaca balx dan balz sebelum transaksi
T5 lengkap di-update.
• Masalah lainnya dapat terjadi jika transaksi T
membaca ulang item data yang sebelumnya
telah dibaca. Tetapi, di samping itu transaksi
yang lainnya telah mengubahnya. Dengan
demikian, T menerima dua nilai yang berbeda
untuk item data yang sama.
Hal ini disebut dengan nonrepeatable (or fuzzy) read.
Masalah serupa dapat terjadi jika transaksi T
mengeksekusi query yang mengambil satu set tupel
dari relasi yang memenuhi predikat tertentu,
mengeksekusi kembali query di lain waktu, tetapi
menemukan bahwa set yang diambil berisi tupel
(phantom) tambahan yang telah dimasukkan oleh
transaksi lain untuk sementara. Hal ini seringkali
disebut sebagai read phantom.
Serializability dan Recoverability
Tujuan protokol concurrency control adalah untuk
menjadwalkan transaksi sedemikian rupa sehingga dapat
menghindar dari berbagai gangguan.
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.
Dalam bagian ini, kita memeriksa serializability sebagai
sebuah cara untuk membantu mengidentifikasi eksekusi
transaksi tersebut yang dijamin untuk memastikan
konsistensi.
Schedule
Schedule adalah sebuah urutan dari operasi-operasi
oleh satu set transaksi yang jalan bersamaan yang menjaga
urutan operasi pada setiap transaksi individual.
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 scheduletersebut. 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.
NonSerial Schedule adalah sebuah schedule di mana operasioperasi dari satu set concurrent transactions mengalami
interleaved.
Pada sebuah serial schedule, transaksi dijalankan pada serial
order.
Lalu, pada eksekusi serial tidak ada interferensi antara
transaksi
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.
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.
Keterangan Gambar :
(a) nonserial schedule A
(b) nonserial schedule B
(c) serial schedule C, ekuivalen dengan A dan B
Schedule Cadalah sebuah schedule serial dan karena A dan B ekuivalen dengan C,
maka A dan B 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.
Terima Kasih