DISTRIBUTED TRANSACTIONS
1.Distributed
Transactions
● Proses
transaksi (flat / nested) yang mengakses object yang dikelola oleh beberapa server
● Konsep
atomicity tetap berlaku (all or nothing)
● Diperlukan
sebuah coordinator untuk memastikan konsep atomicity
● Menggunakan
protokol yang sudah disepakati sejak awal (twophase commit protocol)
● Memerlukan
concurrency control
2.Flat
Transaction (1)
● Sebuah
client melakukan request pada lebih dari satu server
● Sebuah
transaksi diselesaikan dahulu sebelum meminta ke server berikutnya (sequential)
● Jika
menggunakan konsep locking, maka sebuah transaksi hanya bisa menunggu satu obyek saja
3.Nested
Transactions (1)
● Top
level transaction bisa membuat sub transaksi
● Sub
transaksi pada level yang sama bisa berjalan secara concurrent (parallel)
● Mampu
memanfaatkan utilitas prosessor (pada kasusmulti processor)
4.PROSES
TRANSAKSI
● Client
mengirimkan request openTransaction pada coordinator pada sembarang server
● Coordinator
yang dituju mengembalikan identifier transaction yang unik pada client
● Client
bekerjasama dengan coordinator dengan commit protocol
5.Coordinator
(1)
● Sebuah
host/system yang menjadi "mandor" untukmenyelesaikan
sebuah transaksi terdistribusi
● Bertanggung
jawab untuk mengambil keputusan commit/abort
● Selama
terjadi transaksi, coordinator mencatat daftar referensi dari partisipan dan vice versa
● Coordinator
tahu semua daftar peserta dan vice Versa
6.Atomic
Commit Protocols
● Dikembangkan
awal 1970an
● Bertujuan
untuk memastikan bahwa setiap perubahan terjadi pada semua systematau tidak sama
sekali (all or nothing)
● Terdapat
tiga jenis
- One
phase commit protocol
- Two
phase commit protocol
- Three
phase commit protocol
● Berakhir
setelah transaksi di commit/abort
7.One
Phase Commit Protocol
● Coordinator
mengirimkan pesan commit atau abort pada semua partisipan
● Proses
diulang terus menerus sampe semua sudah membalas
● Masalah
: Tidak mungkin melakukan abort setelah ada permintaan untuk commit
● Solusi
: Two Phase Commit
7.1.Two
Phase Commit Protocol (1)
● Fase
1 (voting)
- Coordinator
mengirimkan request canCommit pada setiap partisipan
- Partisipan
memilih yes/no dan mengirim balik pada coordinator. Jika yes, maka menyimpan obyek
pada penyimpanan
permanen. Jika tidak, abort
7.2.Two
Phase Commit Protocol (2)
● Fase
2
- Coordinator
mengumpulkan hasil voting
- Jika
semua setuju, coordinator memutuskan commit dan mengirimkan doCommit pada semua partisipan
- Selain
itu, coordinator memutuskan abort dan mengirimkan doAbort pada semua partisipan yang memilih
yes
- Partisipan
yang memilih yes menunggu doCommit/ doAbort dari coordinator
7.3.Two
Phase Commit Protocol (3)
● Setelah
menerima salah satu dari pesan diatas, partisipanmenjalankan perintah sesuai dengan pesan yang
diterima
● Jika
dilakukan perintah commit, maka partisipanmengirimkan pesan haveCommitted pada
coordinator sebagai konfirmasi bahwa proses sudah dilaksanakan
8.Masalah
pada Two Phase Commit
● Susah
memastikan semua partisipan sudah melakukan vote dan mendapatkan hasil yang sama
● Jika
proses mengalami kegagalan (terjadi network partitioning),maka tidak akan didapatkan
konsensus, karena partisipan yang lain akan saling menunggu (blocking)
● Solusi
: three phase commit
8.1.Three
Phase Commit
● Mencoba
mengatasi masalah blocking
● Menggunakan
asumsi tidak lebih dari k site fail (k adalah angka yang sudah disetujui)
● Coordinator
memastikan bahwa paling tidak k site lain tahu bahwa coordinator akan melakukan
commit
● Jika
coordinator fail, site yang lain melakukan election
coordinator baru dan melihat status terakhir dan menentukan aksi (commit/abort)
8.2.Masalah
pada Three Phase Commit
● Susah
implementasinya
● Harus
memastikan bahwa state harus tetap konsistenmeskipun terdapat perbedaan hasil (transaksi
dicommit di
satu site dan abord di site yang lain sebagai akibat dari network partitioning)
● Terlalu
banyak overhead
9.Concurrency
Control
● Setiap
server mengelola sekumpulan obyek dan bertanggung jawab untuk memastikan
tetap
konsisten ketika diakses oleh transaksi concurrent
● Jenis
- Locking
- Timestamp
ordering concurrency control
- Optimistic
concurrency control
● Baca
materi minggu kemarin
10.Distributed
Locking (1)
● Lock
pada obyek dikendalikan secara lokal oleh
local
lock manager
- Memberikan
akses untuk lock
- Membuat
transaksi yang meminta request menunggu
● Tidak
bisa melepas lock sampai ada kepastian
abort/commit
pada semua server
● Bisa
menimbulkan distributed deadlock
11.Phantom
Deadlock (1)
● Deadlock
yang terdeteksi tetapi bukan merupakan sebuah deadlock
● Terjadi
karena adanya delay pada saat pengiriman informasi deadlock pada jaringan
11.1Phantom
Deadlock (2)
● Transaksi
U melepas obyek pada server X
● Transaksi
U meminta V pada server Y
● Asumsi
- Server
Y diterima terlebih dahulu dibandingkan server X
● T
>U >V >T
● T
>U sudah tidak ada lagi
12.Logging
● Semua
transaksi yang commit dicatat pada log
● Urutan
entry menggambarkan urutan transaksi
● Setelah
crash, semua transaksi yang tidak memiliki status committed akan dibatalkan