Protocol Transaksi konkruen

Proses pengelolaan operasi pada basis data secara simultan tanpa saling berinterferensi satu sama lain.

Pengaksesan konkuren yg hanya membaca data, tidak akan saling ber-interferensi, tetapi apabila ada yg mengupdate data, akan saling berinterferensi & menyebabkan terjadi ketidakkonsistenan.

Akses konkuren tidak akan bermasalah jika user hanya melakukan pembacaan data saja, gangguan akan terjadi jika dua atau lebih user mengakses database secara simultan dan sedikitnya melakukan satu perubahan (update), maka dapat menyebabkan ketidak-konsistenan (inconsistencies).

3 Masalah akibat concurrency

1.       Lost update (modifikasi yg hilang)

Masalah operasi update yg sukses dari seorang pengguna kemudian ditimpali oleh operasi update dari pengguna lain.

Contoh diatas menerangkan hilangnya modifikasi yang dilakukan oleh T2. Kehilangan modifikasi ini dapat diatasi dengan mencegah T1 melakukan pembacaan data sebelum perubahan T2 selesai dilaksanakan.

2.       Uncommited dependency (ketergantung an yg tidak sukses/modifikasi sementara)

Masalah terjadi saat suatu transaksi membaca data dari transaksi lain yg belum dicommit. Misalkan masalah modifikasi sementara terjadi jika satu transaksi (transaksi pertama) membaca hasil dari transaksi lainnya (transaksi kedua) sebelum transaksi kedua dinyatakan committed. Biasa dikenal dengan dirty read problem.

Contoh transaksi T4 merubah balx menjadi £200 tetapi digagalkan, sehingga balx harus dikembalikan ke nilai awal sebelum transaksi yaitu £100. Sedangkan transaksi T3 membaca nilai hasil modifikasi tadi yaitu, balx (£200) dan menguranginya dengan £10, sehingga memperoleh nilai akhir £190, yang seharusnya £90.

Masalah tersebut dapat dihindari Problem dengan mencegah T3 membaca balx sebelum T4 dinyatakan committed  atau abort.

3.       Inconsistent analysis

Masalah terjadi saat satu transaksi membaca beberapa nilai tetapi transaksi kedua pd waktu sama memodifikasi nilai tersebut.

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).

Hal ini disebut dengan nonrepeatable ( or fuzzy) read.

Masalah tersebut dapat dihindari dengan mencegah transaksi T6 membaca balx dan balz sebelum transaksi T5 lengkap di-update.

Objektif pengontrolan konkurensi

Penjadualan transaksi untuk mencegah adanya saling interferensi. Hanya satu transaksi dieksekusi pada satu waktu : satu transaksi di-commit sebelum transaksi lain diperkenankan untuk mulai. Transaksi dapat dilakukan pada sistem paralel, dengan cara penjadualan bersama.

SERIALIZABILITY

Schedule atau jadual merupakan urutan dari operasi read & write secara bersamaan pada sekumpulan transaksi yg konkuren. Serial schedule merupakan jadual dimana operasi2 setiap transaksi dieksekusi secara berurutan tanpa terselip operasi dari transaksi lain. Nonserial schedule merupakan jadual dimana operasi2 dari sekumpulan transaksi konkuren dapat saling menyelip. Serializable berarti jika jadual (nonserial) menghasilkan hasil yg sama seperti halnya jadual serial lainnya.

Urutan operasi sangat penting

·         Jika 2 transaksi hanya melakukan operasi read data, maka tidak terjadi konflik & urutan operasi tidak penting.

·         Jika 2 transaksi melakukan operasi read & write pada data yg berbeda, maka tidak terjadi konflik & urutan operasi tidak penting.

·         Jika satu transaksi melakukan operasi write data & yg lain melakukan operasi read & write pada data yg sama, maka urutan eksekusi sangat penting.

Metode untuk menjamin serializability

1. LOCKING

2. TIMESTAMPING

Keduanya konservatif (pesimistik) karena transaksi ditunda untuk mencegah konflik dg transaksi lain di waktu kemudian.

Metode Optimistic

Berasumsi bhw konflik jarang terjadi sehingga proses tetap berjalan & pengecekan dilakukan pada saat transaksi sudah di-commit.

Metode Locking

Prosedur untuk mengontrol pengaksesan data secara konkuren. Ketika satu transaksi mengakses database, sebuah kunci (lock) dapat mengabaikan akses untuk transaksi lainnya, untuk menghindari hasil yang salah.

Secara umum, transaksi harus menegaskan penguncian (lock) shared (read) atau exclusive (write) terhadap data item sebelum pembacaan (read) atau penulisan (write).

Aturan dasar penguncian (locking):

·         Shared Lock, jika transaksi memiliki shared lock pada suatu data item, maka transaksi tersebut dapat melakukan pembacaan tetapi tidak melakukan perubahan.

·         Exclusive Lock, Jika transaksi memiliki exclusive lock pada suatu data item, maka transaksi tersebut dapat melakukan pembacaan dan perubahan terhadap data item tersebut.

Penggunaan kunci (lock) :

Transaksi yg akan mengakses suatu data harus terlebih dahulu menguncinya, meminta kunci S jika hanya melakukan read data saja atau kunci X jika untuk melakukan operasi read & write. Jika data tsb belum dikunci oleh transaksi apapun, maka kunci diperkenankan.

Jika item tersebut telah dikunci, DBMS menentukan apakah permintaan sesuai dengan penguncian yang ada. Jika yang digunakan adalah shared lock maka permintaan akan diberikan, jika bukan (exclusive lock) maka transaksi harus menunggu kunci tersebut dilepaskan.

Transaksi terus menahan suatu kunci sampai dilepaskan secara eksplisit selama eksekusi atau telah selesai.

Matriks LOCKING

Protokol Two-Phase Locking (2PL)

Protokol untuk menjamin serializability. Suatu transaksi menggunakan protokol 2PL jika seluruh operasi penguncian (locking) mendahului operasi pelepasan kunci (unlock) dalam transaksi.  Terdapat dua fase untuk transaksi, yaitu                :

·         Growing phase – mendapatkan seluruh kunci tetapi tidak dapat melepaskan kunci.

·         Shrinking phase – melepaskan kunci tetapi tidak mendapatkan kunci baru.

Aturan dasar 2PL

Satu transaksi harus meminta sebuah kunci untuk suatu iter sebelum melaksanakan operasi pada item tersebut. Kunci yang diminta dapat berupa write lock maupun read lock , tergantung kebutuhan

Sekali transaksi melepaskan kunci, maka transaksi tersebut tidak dapat meminta kunci yang baru.

Deadlock

Deadlock merupakan kebuntuan (impasse) yang mungkin dihasilkan ketika dua atau lebih transaksi saling menunggu  kunci yang disimpan oleh transaksi lain agar dilepaskan.

Tiga teknik yang umum dilakukan untuk mengatasi deadlock       : 

Timeout

-          Dengan pendekatan timeout, suatu transaksi yang meminta kunci hanya akan menunggu sistem mendefinisikan periode waktu. 

-          Jika kunci belum diberikan dalam periode ini, maka permintaan kunci kehabisan waktu (times out).

-          Dalam kasus ini, DBMS mengasumsikan transaksi terjadi deadlocked, walaupun mungkin tidak terjadi, dan transaksi tersebut digagalkan dan secara otomatis mengulang dari awal transaksi yang bersangkutan.

·         Deadlock prevention

-          Pendekatan lain yang mungkin dilakukan untuk menghindari deadlock adalah memerintahkan transaksi menggunakan transaksi timestamps :

§  Wait-Die – memungkinkan hanya transaksi lama menunggu traksaksi baru, selain itu transaksi digagalkan (dies) dan diulang dengan timestamps yang sama.

§  Wound-Wait – hanya transaksi baru yang menunggu transaksi lama. Jika transaksi lama meminta kunci yang dimiliki oleh transaksi baru, maka transaksi baru akan digagalkan  (wounded).

·         Deadlock detection and recovery

-          Pendeteksian deadlock biasanya ditangani dengan membuat konstruksi Wait For Graph (WFG) yang memperlihatkan ketergantungan transaksi, yaitu transaksi Ti bergantung pada Tj jika transaksi Tj memegang kunci untuk data item yang ditunggu olah Ti.

-          WFG merupakan graf berarah (directed graph) G =(N, E), yang dapat debentuk dengan cara :

§  Buatlah Node untuk setiap transaksi

§  Buatlah edge berarah Ti -> Tj, jika Ti menunggu kunci untuk item yang sedang dikunci oleh Tj.

-          Deadlock terjadi jika dan hanya jika WFG mengandung siklus.

-          Recovery basis data merupakan suatu proses penyimpanan kembali basis data pada keadaan yang benar sebelum terjadi kegagalan(failure).