SISTEM TERDISTRIBUSI

Distributed Transaction

Ferri.andrinato (093112700650051)

JURUSAN SISTEM INFORMASI FAKULTAS TEKNOLOGI KOMUNIKASI dan INFORMASI UNIVERSITAS NASIONAL

Distributed Transaction
Biasanya transaksi flat atau nested mengakses objek yang berada pada satu server tunggal. Namun dalam kebanyakan hal, sebuah transaksi , apakah itu nested atau flat, akan mengakses objek yang ditempatkan pada server yang berbeda-beda. Dalam hal ini, kita gunakan terminologi distributed transaction untuk merujuk pada transaksi flat maupun nested yang mengakses objek yang dikelola oleh lebih dari satu komputer server.

Ketika distributed transaction diperkenalkan di akhir-akhirnya, atmocity property dari transaksi mensyaratkan bahwa baik semua server yang terlibat mengikatkan diri pada transaksi ataupun semua server tersebut justru menghentikan transaksi. Demi memnuhi tujuan ini, sebuah server mengabil alih peran koordinator yang melibatkan pemastian outcome yang sama pada setiap server. Cara ayng ditempuh oleh koordiantor untuk melakukan hal ini, bergantung pada protokol yang dipilih. Sebuah protokol yang dikenal sebagai two -phase commit protocol merupakan protokol yang biasa digunakan. Protokol ini memungkinkan server untuk berkomunikasi satu dengan yang lainnya untuk mencapai kesepakatan bersama baik dalam commit maupun abort. Kontrol konkurensi dalam transaksi terdistribusi berdasar pada metode . Masing-masing server menerapkan kendali konkurensi lokal pada objeknya masing-masing, yang mana kendali ini memastikan bahwa transaksi terserialisasi secara lokal. .

TRANSAKSI TERDISTRIBUSI FLAT DAN NESTED

Sebuah transaksi klien menjadi terdistribusi jika ia melibatkan beberapa operasi pada beberapa server. Ada dua cara diaman trnasaksi terdistribusi dibentuk, yakni nested transactiondan flat transaction. Pada flat transaction, sebuah client membua request pada lebih dari satu server. Sebagai contoh pada gambar 1.1 berikut, transaksi T merupakan transaksi flat yang melibatkan operasioperasi terhapdap objekobjekpada server X, Y, dan Z. Sebuah flattransactionmelengkapitiaptiap requestnya sebelumbernangkatke ke transaksi selanjutnya. Oleh karenanya, tipa-tiap trnasaksi mengaksesobjek server secara sekuensial. Ketika sebuah server dikunci, makatransaksi hanya bisa menunggu satu objek saja pada satu waktu.

Pada nested transaction, transaksi yang berada pada level atas dapat membuka beberapa sub-transaksi dan tiap-tiap sub-transaksi tersebut dapat juga membuka sub-transaksi lagi seterusnya sampai beberapa tingkat. Gambar 1.2 menunjukkan trnasaksi klien T yang membuka dua sub transaksi T1 dan T2, yang mengakses objek pada server X dan Y. Sub-transaksi T1 dan T2 tersebut membuka sub-transaksi lagi, yakni T11, T12, T21, dan T22 yagn mengakses objek pada server M, N, dan P. Dalam kasus transakasi bertingka seperti ini, sub transaksi yang berada pada level yang sama dapat berjalan secara serrempak (konkuren), sehingga T1 dan T2 konkuren, dan karena mereka melibatkan objek pada server yang berbeda, maka mereka dapat nerjalan secara paralel. Keempat sub-transaksi T11, T12, T21, T22 juga berjalan secara konkuren satu dengan lainnya.maka mereka dapat nerjalan secara paralel. Keempat sub-transaksi T11, T12, T21, T22 juga berjalansecara konkuren satu dengan lainnya.

Gambar 1. Flat dan Nested Transaction Taruhlah sebuah transaksi terdistribusi, dimana sebuah klien mentransfer $10 dari account A ke account C dan kemudian mentransfer $20 dari account B ke D. Account B dan D berada pada server yang terpisahX dan Y, sementara account C dan D berada pada server Z. Jika transaksi ini dissun sebagai satu set berisiempat transaksi nested, sebagaimana pada Gambar, maka keempat request (dua deposit dan dua withdraw)dapat berjalan secara paralel dan dampak sercara keseluruhan dapat mempengaruhi kinerja yang lebih baikdaripada seuah transaksi sederhana berisi empat transaksi yang berjalan secara sekuensial.

Gambar 2. Transaksi Nested pada Perbankan

Gambar 3. Sebuah Transaksi Terdistribusi pada Perbankan

ATOMIC COMMIT PROROCOL

A. Two Phase Commit Protocol Selama Progre Transaksi, tidak ada komunikasi apapun antara koordinator dan partisipan dari partisipan yang memberi informasi pada koordiantor ketika mereka menggabungkan transaksinya.Sebuah reques dari clien untuk mengikatkan (atau menlepaskan) transaksi diarahkan ke koordiantor. Jikaklien merequest abortTransaction, atau jika transaksi dilepas oleh partisipan, maka kordinator segera memberitahu partisipan. Itu terjadi ketika klien meminta koordinator untuk mengikatkan transaksinya pada two-phase commit protocol yang datang kedalam penggunaan. B. Two Phase Commit Protocol untuk Nested Transaction Transaksi yang paling luar dari sebuah transaksi nested disebut sebagai top-level transaction. Pada Gambar 2, T adalah top-level transaction, sedangkan T11, T12, T21, T22 merupakan sub transaction. Tiap-tiap sub transaksi dimulai setelah transaksi induknya memulai dan berakhisr sebelum transaksi induknya berakhir. Sebagai contoh, T11 dan T12 dimulai setelah T1 dan berakhir sebelumnya.

CONTROL PERSETUJUAN PADA TRANSAKSI TERDISTRIBUSI

Control Persetujuan pada Transaksi ini memiliki maksud agar saat sistem diakses maka keberlangsungan dari sistem tersebut akan tetap ada. Untuk menjalankan tujuan ini terdapat beberapa cara yang dapat digunakan. A. Locking Pada cara yang pertama ini server melakukan penguncian terhadap transaksi yang sedang berlangsung pada server tersebut. Sehingga apabila terdapat server lain yang ingin menggunakan hak akses padatransaksi itu harus menunggu hingga server yang mengunci transaksi itu memberikan hak akses kepada server yang ingin menggunakannya. Masalah yang sering muncul adalah saat terdapat server-server yang untuk memberikan hak akses harus saling menggunakan transaksi berseberangan yang sudah di-lock. Pada akhirnya kedua server hanya akan saling menunggu satu sama lain untuk menyelesaikan prosesnya (deadlock).

B. Timestamp Ordering Cara yang kedua ini adalah dengan memberikan timestamp pada setiap proses transaksi. Dengan adanya timestamp ini maka akan diberikan jadwal akses transaksi pada setiap server. Dengan demikian prosesyang terjadi pada transaksi akan terus berlangsung walaupun waktu masing-masing server tidak sinkron,hal ini dikarenakan timestamp hanya dikeluarkan oleh koordinator server. C. Control Optimistic Concurrency Untuk Control Optimistic ini apabila ingin melakukan akses terhadap transaksi, maka harus dilakukan dikerjakan terlebih dulu proses urutan eksekusinya. Barulah transaksi dieksekusi berdasarkan pengurutan yang sebelumnya dilakukan. Dalam proses ini juga dibutuhkan validasi pada setiap transaksi yang masukdan diberikan nomor urut.

DEADLOCK TERDISTRIBUSI
Deadlock yang terjadi biasanya dikarenakan proses locking pada transaksi. Untuk menduga terjadinya deadlock adalah dengan melihat lama waktu proses pada server, apabila hingga suatu interval waktutimeout masih belum juga dapat menyelesaikan prosesnya (transaksi), maka kemungkinan terjadideadlock. Cara ini bisa dilakukan dengan melihat gambar proses transaksi secara keseluruhan. Apabilaterjadi cycle yang berulang-ulang maka kemungkinan terjadi deadlock akan besar.

Gambar 3. Deadlock Terdistribusi

A. Phantom Deadlock Apabila diduga terjadi deadlock maka server akan mengirimkan status transaksi kepada manager. Selanjutnya kan dilakukan perhitungan terhadap proses yang sedang berlangsung. Hasilnya dalah sebuah grafik wait-for yang terjadi pada server-server participant. Saat proses perhitungan sedang berlangsung server dapat saja telah memutuskan (abort) transaksi yang sedang berlangsung padanya. Akan tertapikarena perhitungan yang dihasilkan berdasarkan proses sebelumnya maka akan tetap terdeteksi deadlock.

Gambar 4. Phantom Deadlock

B. Edge Chasin Pada edge chasing ini masing-masing server akan berusaha mencari cycle yang mungkin terjadi dengan mengirimkan pesan yang disebut probel. Pesan ini berisi tentang jalur yang dilalui saat terjadi prosestransaksi. Langkahnya adalah sebagai berikut, Gambar 1. Initiation Langkah ini akan dikirimkan probe transaksi namun harus menunggu transaksi lain secara global. Misalnya saja transaksi T menunggu transaksi U di sebuah server lokal sehingga isi dari probe(ada transaksi yang ditunggu U berisi <T->U> ke server lokal) Gambar 2. Detection Selanjutnya isi dari probe akan diterima dan dideteksi ada tidaknyanya deadlock. Bila ternyata Umenunggu V di server lain, maka probe server selanjutnya berisi forwardprobe yang berisi <T>U->V> Gambar 3. Resolution Terakhir apabila deadlock terdeteksi maka transaksi yang sedang berlangsung akan dibatalkan.

DEADLOCK TERDISTRIBUSI
Setiap server menyimpan semua objek yang terdapat di dalamnya. Caranya yaitu saat server sedang berjalan, volatile memory dan record dari objek-objek yang sedang dikerjakan akan dilakukan prosespenyimpanan di dalam recovery file.

Dalam beberapa kasus jika suatu saat data di dalam disk hilang, atau data corrupt ketika terjadicrashmakasetiap server sebelumnya terdapat intentions list pada tempat penyimpanan transaksi. Intention listtransaksi mengandung reference list.Intention list digunakan untuk mengidentifikasi objek yangdijalankan pada saat proses transaksi. Selanjutnya setiap objek akan diganti version transaksinya, dan nilaiyang baru dituliskan sementara pada file recovery di server. Berikut ini beberapa metode yang umum digunakan dalam recovery transaksi

A. Logging Di dalam teknik logging, log yang berisi recovery file direpresentasikan ke dalam sebuah history. Keuntungan menggunakan teknik logging ini adalah penulisan sekuensial ke dalam disk akan lebih cepat dibandingkan menuliskannya secara acak.

Gambar 5. Logging Recovery file

B. Versions Shadow Shadow versions merupakan salah satu cara alternatif untuk mengorganisasi sebuah file recovery. Version shadow mengunakan semacam petauntuk manetapkan versiyang ada pada objek di dalam fileversions store. Untuk mengembalikan crash, recovery manager membaca map dan menggunakaninformasi dari map objek di dalam untuk menempatkan version store transaksi. Metode shadow versionmenghasilkan proses recovery lebih cepat daripada logging karena posisi objek yang dikerjakan pada saatini langsung direkam di dalam map, sedangkan proses recovery pada log membutuhkan pencarian terlebihdulu . Logging mungkin dapat lebih cepat dari shadow versions saat sistem sedang dalam keadaan normal.Hal ini disebabkan karena logging hanya membutuhkan sebuah rangkaian operasi penggabungan pada file,sedangkan shadow versions membutuhkan tambahan stable storage.

Gambar 6. Versions Shadow