Distributed Transaction

Transkripsi

1 Distributed Transaction Muhammad Rijalul Kahfi, Ibnu Hanif, TE Jurusan Teknik Elektro FT UGM, Yogyakarta I. PNEDAHULUAN 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. II. 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 transaction dan 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 operasi-operasi terhapdap objekobjek pada server X, Y, dan Z. Sebuah flat transaction melengkapi tiap-tiap requestnya sebelum bernangkat ke ke transaksi selanjutnya. Oleh karenanya, tipa-tiap trnasaksi mengakses objek server secara sekuensial. Ketika sebuah server dikunci, maka transaksi 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,

2 maka mereka dapat nerjalan secara paralel. Keempat sub-transaksi T11, T12, T21, T22 juga berjalan secara 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 terpisah X dan Y, sementara account C dan D berada pada server Z. Jika transaksi ini dissun sebagai satu set berisi empat 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 baik daripada seuah transaksi sederhana berisi empat transaksi yang berjalan secara sekuensial.

3 Gambar 2. Transaksi Nested pada Perbankan Gambar 3. Sebuah Transaksi Terdistribusi pada Perbankan

4 III. 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. Jika klien 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. IV. 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 pada transaksi 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 proses yang 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

5 yang sebelumnya dilakukan. Dalam proses ini juga dibutuhkan validasi pada setiap transaksi yang masuk dan diberikan nomor urut. V. 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 waktu timeout masih belum juga dapat menyelesaikan prosesnya (transaksi), maka kemungkinan terjadi deadlock. Cara ini bisa dilakukan dengan melihat gambar proses transaksi secara keseluruhan. Apabila terjadi cycle yang berulang-ulang maka kemungkinan terjadi deadlock akan besar. A. Phantom Deadlock Gambar 3. Deadlock Terdistribusi 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 tertapi karena perhitungan yang dihasilkan berdasarkan proses sebelumnya maka akan tetap terdeteksi deadlock.

6 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 proses transaksi. 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 U menunggu V di server lain, maka probe server selanjutnya berisi forward probe yang berisi <T- >U->V> Gambar 3. Resolution Terakhir apabila deadlock terdeteksi maka transaksi yang sedang berlangsung akan dibatalkan. VI. 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 proses penyimpanan di dalam recovery file. Dalam beberapa kasus jika suatu saat data di dalam disk hilang, atau data corrupt ketika terjadi crash maka setiap server sebelumnya terdapat intentions list pada tempat penyimpanan transaksi. Intention list transaksi mengandung reference list. Intention list digunakan untuk mengidentifikasi objek yang dijalankan pada saat proses transaksi. Selanjutnya setiap objek akan diganti version transaksinya, dan nilai yang 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.

7 Gambar 5. Logging Recovery file B. Versions Shadow Shadow versions merupakan salah satu cara alternatif untuk mengorganisasi sebuah file recovery. Version shadow mengunakan semacam peta untuk manetapkan versi yang ada pada objek di dalam file versions store. Untuk mengembalikan crash, recovery manager membaca map dan menggunakan informasi dari map objek di dalam untuk menempatkan version store transaksi. Metode shadow version menghasilkan proses recovery lebih cepat daripada logging karena posisi objek yang dikerjakan pada saat ini langsung direkam di dalam map, sedangkan proses recovery pada log membutuhkan pencarian terlebih dulu. 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 REFERENSI [1] George Colouris, Donlimore, and Tim Kinberg, Distributed System, Concept and Design Addison Wisley Publisher Limited, April 1988.