PERTEMUAN XII (SISTEM TERDISTRIBUSI)

CHAPTER 6
FAULT TOLERANCE

7.4 RELIABLE GROUP COMMUNICATION

Mengingat bagaimana proses ketahanan penting dengan replikasi, tidak mengherankan bahwa layanan multicast handal juga penting. Layanan tersebut menjamin bahwa pesan yang dikirimkan ke semua anggota dalam kelompok proses. Unfor-tunately, multicasting diandalkan ternyata mengejutkan rumit. Pada bagian ini, kita melihat lebih dekat pada isu-isu yang terlibat dalam mati andal menyampaikan pesan ke grup proses.

7.4.1 Basic Reliable-Multicasting Schemes

Meskipun sebagian besar lapisan transportasi menawarkan saluran point-to-point yang dapat diandalkan, mereka jarang menawarkan komunikasi yang handal untuk koleksi proses. Yang terbaik yang bisa mereka tawarkan adalah untuk membiarkan setiap proses mengatur koneksi point-to-point untuk setiap proses lain ingin berkomunikasi dengan. Jelas, organisasi semacam ini sangat tidak efi sien ¬ karena dapat membuang-buang bandwidth jaringan. Namun demikian, jika jumlah proses yang kecil, mencapai keandalan melalui berbagai saluran point-to-point yang dapat diandalkan adalah solusi sederhana dan sering mudah.

Datang ke titik ini, kita perlu mendefinisikan secara tepat apa multicasting diandalkan. Secara intuitif, itu berarti bahwa pesan yang dikirim ke grup proses harus dikirimkan kepada setiap anggota grup itu. Namun, apa yang terjadi jika selama proses komunikasi yang bergabung dengan kelompok? Haruskah proses yang juga menerima pesan? Demikian juga, kita juga harus menentukan apa yang terjadi jika sebuah proses (pengiriman) crash selama komunikasi.

Untuk menutupi situasi seperti ini, perbedaan harus dibuat antara handal com-munication di hadapan proses rusak, dan komunikasi dapat diandalkan ketika proses diasumsikan untuk beroperasi dengan benar. Dalam kasus pertama, multicasting dianggap dapat diandalkan ketika dapat dijamin bahwa semua anggota kelompok nonfaulty menerima pesan itu. Bagian yang sulit adalah bahwa kesepakatan harus dicapai pada apa yang sebenarnya seperti sebelum pesan dapat disampaikan, selain berbagai kendala memesan kelompok. Kita kembali ke hal-hal ini ketika membahas multicast atom di bawah ini.

Situasi menjadi lebih sederhana jika kita asumsikan ada pada kesepakatan yang merupakan anggota kelompok. Secara khusus, jika kita mengasumsikan bahwa proses tidak gagal, dan proses tidak bergabung atau meninggalkan grup sementara komunikasi yang terjadi, multicasting.simply handal berarti bahwa setiap pesan harus disampaikan kepada setiap anggota kelompok saat ini. Dalam kasus yang paling sederhana, tidak ada persyaratan bahwa semua anggota kelompok menerima pesan dalam urutan yang sama, tapi kadang-kadang fitur ini diperlukan.ini bentuk yang lebih lemahdarimulticastinghandalrelatif mudahuntuk menerapkandisediakanlagijumlahpenerimaterbatas. Pertimbangkankasus yangsatu pengiriminginmulticastpesan ke beberapapenerima. Asumsikan bahwasistem komunikasibawahdataranhanya menawarkanmulticastingdiandalkan, yang berarti bahwapesanmulticastmungkin hilangbagian perjalanandan dikirim kebeberapa, tapi tidaksemua, dari dimaksudkanpenerima.

padaGambar-. 7-8. Prosespengirimanmemberikan nomorurut untuk setiappesan yangmulticast pesan yangditerima dalam urutanmereka akan dikirim. Dengan cara ini, mudah bagipenerimauntuk mendeteksifile tersebut tidak adapesan. Setiap pesanmulticastdisimpan secara lokaldalam buffersejarah dipengirim. penerimadiketahuipengirim, pengirim hanya membuatpesandalam buffersejarahsampai setiappenerimatelah kembalipengakuan. Jikapenerimamendeteksihilangpesan, mungkin kembalipengakuannegatif,memintapengirim untukretransmisi. Alternatif masing, pengirimdapat secara otomatismemancarkan kembalipesanketikabelum menerimasemuapengakuandalam kurun waktu tertentu. Ada berbagaidesaintrade-offyang akan dibuat. Juga, mentransmisipesandapat dilakukan dengan menggunakankomunikasipoint-to-point untuksetiap prosesmeminta, ataumenggunakan pesanmulticasttunggal,dikirim kesemua proses

7.4.2 Skalabilitas di Multicasting Handal

Masalah utama dengan skema multicast handal yang baru saja dijelaskan adalah bahwa ia tidak dapat mendukung sejumlah besar penerima. Jika ada penerima N, pengirim harus siap untuk menerima setidaknya N ucapan terima kasih. Selain itu, kita juga mungkin perlu mempertimbangkan bahwa penerima yang tersebar di seluruh jaringan wide-area. Salah satu solusi untuk masalah ini tidak memiliki penerima mengakui penerimaan pesan. Sebaliknya, penerima mengembalikan pesan umpan balik hanya untuk menginformasikan pengirim tersebut tidak ada pesan. Kembali hanya pengakuan negatif seperti dapat ditampilkan untuk umum skala yang lebih baik, Tetapi tidak ada jaminan keras dapat diberikan bahwa implosions umpan balik tidak akan pernah terjadi.

Masalah lain dengan kembali hanya pengakuan negatif adalah bahwa pengirim akan, secara teori, dapat dipaksa untuk menjaga pesan dalam buffer sejarah selamanya. Karena si pengirim tidak pernah bisa tahu apakah pesan telah dikirimkan ke semua penerima, harus selalu siap untuk penerima meminta sion retransmis dari pesan lama. Dalam prakteknya, pengirim akan menghapus pesan dari nya penyangga setelah beberapa waktu telah berlalu untuk mencegah buffer dari meluap. Namun, menghapus pesan dilakukan pada risiko permintaan untuk transmisi tidak dihormati.

Umpan balik Multicasting memungkinkan anggota lain kelompok untuk menekan pakan sendiri kembali. Misalkan beberapa penerima melewatkan pesan m. Masing-masing dari mereka akan perlu untuk mengembalikan pengakuan negatif ke pengirim, S, sehingga m dapat Retransmit ¬ ted. Namun, jika kita berasumsi bahwa retransmisi selalu multicast ke gimp keseluruhan, sudah cukup bahwa hanya satu permintaan untuk pengiriman ulang mencapai S. Untuk alasan ini, R penerima yang tidak menerima jadwal m pesan umpan ¬ pesan kembali dengan beberapa penundaan acak. Artinya, permintaan untuk pengiriman ulang tidak dikirim sampai beberapa waktu acak telah berlalu. Jika, sementara itu, permintaan lain untuk pengiriman ulang untuk m mencapai R, R akan menekan umpan balik sendiri, mengetahui bahwa m akan dipancarkan kembali segera. Dengan cara ini, idealnya, hanya pesan umpan balik tunggal akan mencapai S, yang pada gilirannya kemudian mentransmisikan kembali m. Skema ini ditunjukkan pada Gambar.

Umpan balik telah menunjukkan untuk skala cukup baik, dan telah digunakan sebagai mekanisme yang mendasari untuk sejumlah aplikasi internet kolaboratif, seperti papan tulis bersama. Namun, pendekatan ini juga memperkenalkan sejumlah masalah serius. Pertama, memastikan bahwa hanya satu permintaan untuk pengiriman ulang dikembalikan ke pengirim membutuhkan penjadwalan yang cukup akurat dari umpan mes ¬ bijak di masing-masing penerima. Jika tidak, penerima masih banyak akan kembali umpan balik mereka pada waktu yang sama. Mengatur timer sesuai dalam kelompok proses yang tersebar di seluruh jaringan wide-area ini tidak mudah.

Hierarchical Feedback Kontrol

Umpan balik penindasan seperti yang baru saja dijelaskan pada dasarnya adalah solusi nonhierarchical. Namun, mencapai skalabilitas untuk kelompok yang sangat besar penerima mensyaratkan bahwa pendekatan hirarkis yang diadopsi. 

7.4.3  Atomicity Multicast

Untuk melihat mengapa atomicity sangat penting, mempertimbangkan con database direplikasi ¬ structed sebagai aplikasi di atas sistem yang terdistribusi. Sistem terdistribusi menawarkan fasilitas multicasting handal. Secara khusus, memungkinkan pembangunan kelompok proses yang pesan dapat dikirim andal. Database direplikasi karena itu dibangun sebagai kelompok proses, satu proses untuk setiap replika. Operasi update selalu multicast untuk semua replika dan kemudian dilakukan secara lokal. Dengan kata lain, kita berasumsi bahwa protokol replikasi aktif digunakan.Misalkan sekarang bahwa serangkaian pembaruan yang akan dilakukan, tetapi selama pelaksanaan salah satu pembaruan, crash replika. Akibatnya, pembaruan yang hilang untuk replika itu, tetapi di sisi lain, itu benar dilakukan di replika lainnya.

Ketika replika yang baru saja jatuh pulih, dapat pulih ke kondisi yang sama itu sebelum kecelakaan, namun mungkin telah terjawab beberapa update. Pada saat itu, adalah penting bahwa itu dibawa up to date dengan replika lainnya. Membawa replika ke negara yang sama seperti yang lain mengharuskan kita tahu persis mana operasi itu terjawab, dan di mana urutan operasi ini harus dilakukan.

Dimisalkan suatu kode program yang melakukan proses transfer dari suatu rekening. Pertama, pastikan apakah dananya cukup, jika cukup, proses transfer terjadi. Jika sesudah mengecek dana, eksekusi diganti dengan thread untuk menghapus dana tersebut, maka akan menyebabkan proses transfer yang invalid ketika proses eksekusi kembali ke thread awal. Mengatur akses rekening sehingga hanya satu thread yang bisa mengakses rekening tersebut, dalam satu waktu akan memperbaiki masalah dan menjadikan transfer tersebut “atomic”.

Suatu operasi atomic adalah proses yang mana menyelesaikan seluruh prosesnya sampai selesai, atau mengembalikan sistem ke kondisi awal. Operasi transfer pada bank pastinya merupakan suatu operasi atomic karena melibatkan 2 langkah. Dalam proses melakukan langkah-langkah tersebut, sangat mungkin kehilangan operasi atomicity jika thread yang lain melakukan modifikasi terhadap rekening sebelum proses transfer selesai.

Identifikasi dan implementasi atomicity merupakan salah satu kerumitan utama dalam pemrograman multithreading.Kerumitannya bertambah karena secara umum statemen dalam C# tidak secara penuh memerlukan atomic. _Count++, sebagai contohnya, merupakan statemen dalam C#, tetapi diterjemahkan menjadi beberapa instruksi untuk processor.

1.    Proses membaca data dalam Count.

2.    Processor mengkalkulasikan nilai yang baru.

3.    Nilai baru diberikan pada Count (walaupun ini mungkin bukan atomic).

Sesudah data diakses, tetapi sebelum nilai baru diberikan, thread yang lain mungkin akan memodifikasi nilai aslinya.

Virtual sinkroni

Multicast handal di hadapan kegagalan proses dapat didefinisikan secara akurat dalam hal kelompok proses dan perubahan keanggotaan kelompok.Dalam hal ini lapisan komunikasi, pesan yang dikirim dan diterima. Sebuah pesan yang diterima secara lokal buffered dalam lapisan komunikasi sampai dapat dikirimkan ke aplikasi yang logis ditempatkan pada lapisan yang lebih tinggi.

Prinsip sinkroni maya berasal dari fakta bahwa semua multicast terjadi antara perubahan tampilan. Dengan kata lain, perubahan pandangan bertindak sebagai penghalang di mana multicast tidak bisa lewat. Dalam arti, hal ini sebanding dengan penggunaan variabel sinkronisasi di toko data terdistribusi seperti yang dibahas dalam bab sebelumnya. Semua multicast yang transit sementara perubahan pandangan terjadi adalah com ¬ pleted sebelum perubahan pandangan diberlakukan. Pelaksanaan sinkroni virtual tidak sepele seperti yang kita akan membahas secara rinci di bawah.

telah dikatakan mengenai Urutan multicast. Secara umum, empat orderings yang berbeda dibedakan:

1.    unordered multicast

2.    FIFO-memerintahkan multicast

3.    Kausal-memerintahkan multicast

4.    Benar-benar-memerintahkan multicast

Sebuah handal, unordered multicast adalah multicast hampir sinkron di mana tidak ada jaminan yang diberikan mengenai urutan yang menerima pesan yang disampaikan oleh proses yang berbeda. Untuk menjelaskan, menganggap bahwa multicasting handal didukung oleh perpustakaan menyediakan mengirim dan menerima primitif. Menerima blok operasi proses pemanggilan sampai pesan yang disampaikan untuk itu.

7.5 DISTRIBUTED COMMIT

Phase commit merupakan operasi dimana satu set perubahan yang nyata juga diterapkan sebagai operasi tunggal. Jika perubahan yang diterapkan maka commit atomis dikatakan telah berhasil. Jika ada kegagalan sebelum commit atomis dapatdi selesaikan maka semua perubahan selesai maka semua perubahan diselesaikan dalam commit atomis reserved. Hal ini memastikan bahwa sistem selalu ditinggalkan dalam keadaan konsisten.

7.5.1  FaseDuaTahap ( Two-phase commit /2PC)

Two-phase commit adalah protocol yang paling sederhana untuk menjaga commitment atomic dari transaksi trdistribusi. Ini memperlebar efek dari aksi local atomic commit pada transaksi terdistribusi dengan semua site pada saat melakukan eksekusi distribusi setuju untuk melakukan commit sebelum efek tersebut menjadi permanent. Jika seluruh site setuju melakukan commit maka semua aksi dari transaksi terdistribusi baru mendapatkan efek. Jika tidak ada satupun site yang mengkomit operasi tersebut maka semua operasi harus membatalkan transaksi tersebut. Oleh karenanya dasar dari aturan 2PC menyatakan:

1.      Jika tidak satupun site yang menyatakan commit maka transaksi dibatalkan.

2.      Jika semua site melakukan commit maka transaksi tersebut dijalankan.

2PC ataufaseduatahapberoperasi di duatahapyaitu:tahappemilihan (Voting phase) dantahapkeputusan (decision phase). Ide dasarnyaadalahketika coordinator(coordinator) bertanyakepadasemuapeserta(participants)apakahmerekatelahsiapmenyelesaikantransaksi. 

Gambar : (a) koordinator (b) peserta

Jikaadasatupesertamemutuskandanmemberikanresponuntukmenghentikan(abort), ataugagal (fails) padasaatwaktu yang telahditentukan, makacoordinatormenginstruksikansemuapersertauntukmenghentikantransaksi. Dan jikasebaliknyasemuakeputusansetuju di selesaikancommit,makacoordinatormenginstrusikanmenyelesaikantransaksi. Keputusan global diberikanolehsemuapeserta .Namunjikaadapesertamemutuskanuntukmenghentikantransaksi,laludengansegeradilakukanpenghentiantransaksi, sebelumwaktu yang telah di tentukanuntuk di putuskanataupununtukdiselesaikantransaksinya, inidinamakandenganunilateral abort .

Jikaadapesertamemutuskanuntukmenyelesaikantransaksi, makaharusmenunggu coordinator untukmenyebarkanpesannya global commit atau global abort. Protokolinimengasumsikanbahwasetiaplokasimemiliki log localsendiri ,dandapatmeroolbackataumelakukan commit  jikatransaksitersebutdapatdiandalkan. Faseduatahapinimelibatkanpesan  yang dikirimdaribeberapalokasi. Untukmenghindariproses  penahanan yang tidakdiperlukan , digunakanperiodewaktu yang ditentukan.

Prosedur yang dilakukancoordinatorpadasaatcommit :

Phase 1:

Tulisbegin_commitkedalam log file danmenuliskannyakedalampenyimpanan datayang stabil (stable storage). KirimsebuahpesanPREPAREkesemuapeserta. Tunggupesandaripesertauntukmerespondenganperiodewaktutertentu.

Phase 2:

JikaseorangpesertakembalidanmemilihABORT,Tulisrecord abortkedalam log file danmenuliskannyakedalampenyimpanan yang stabil (stable storage).KirimpesanGLOBAL ABORTkesemuapeserta.Tunggupesandaripesertauntukmerespondenganperiodewaktutertentu.JikaseorangpesertakembalidanmemilihCOMMIT,Tulisrecord commitkedalamlog file danmenuliskannyakedalampenyimpanan yang stabil (stable storage).KirimpesanGLOBALCOMMITkesemuapeserta Tunggupesandaripesertauntukmerespondenganperiodewaktutertentu.Ketikasemuarespontelahditerima,tulisend_transactionkedalam log file. Jikaadasatulokasi yang tidakmerespon, kirimkembalikeputusan global sampaisemuarespon di terima.

Koordinatorharusmenunggusampaisemuakeputusantelahditerimaolehsemuapeserta.Jikaadasatulokasigagaluntukmemutuskan,makakoordinotrharusmengasumsikankeputusannyaABORTdanmengirimanpesanGLOBAL _ABORTkesemuapeserta.

Prosedur yang dilakukanolehpesertapadasaatcommit :

1.      KetikapesertamenerimasuatupesanPREPARE,  kemudiansalahsatunya :

a.       Tulisready_commitrekampada log file dan force-write adalahpenyimpananarsip log file disimpanpada storage. Mengirimkansuatupesankesiapanbagikoordinator; atau

b.      Tulissuaturekamanpembatalanpada log file dan force-write kepenyimpanan yang stabil. Mengirimkansuatupesanpembatalanbagikoordinator.Secarasepihakmenggugurkantransaksi.

2.      Menantikancoordinatoruntukmenjawab di dalamsuatuperiode timeout.

a.       Jikapesertamenerimasuatupesanpembatalan global, tulissuatucatatanpembatalanpada log file dan force-write ketempatpenyimpanan yang stabil. Membatalkantransaksidanpenyelesaian, mengirimkansuatupengakuankepadakoordinator.

b.      Jikapesertamenerimasuatupembatalan global, Tuliscatatankesediaankepada log file dan force-write kegudangpenyimpanan. Melakukantransaksi, melepaskankunci yang dipegang, danpadapenyelesaianmengirimkansuatulaporankepadakoordinator.

Jikaseorangpesertagagaluntukmenerimasuatukeputusandarikoordinator, halinihanyamembuangwaktudantransaksidihentikan.Olehkarenanya, pesertabiasmembatalkandanmelakukan proses pembatalanlocalsebelumkeputusan di ambil. Proses padasaatpesertamemutuskanuntukselesaiatauberhenti. Pesertaharusmenungguuntukinstruksi GLOBAL_COMMIT atau GLOBAL_ABORT darikoordinator.Jikapesertagagaluntukmenerimainstruksidarikoordinator, ataucoordinatorgagalmenerimatanggapandaripeserta, diasumsikanbahwalokasitelahgagaldanProtokolpenghapusan (Termination protocol) harusdilibatkan. Hanyalokasi yang beroperasional yang mengikutiprotocolpenghapusantersebut;lokasi yang gagalmengikutiprotocolperbaikan ( Recovery Protocol )untuk di restart.

Terdapat dua pergantian pesan antara koordinator dengan partisipan,yang disebut dengan protokol 2PC. Terapat beberapa variasi dari 2PC trsebut, seperti linier 2PC dab distributed 2PC, yang tidak banyak ditemukan pada vendor – vrndor DBMS terdistribusi. Dua varian yang paling penting dari 2PC adalah presumed abort2PC dan presumed commit 2PC. Kedua varian itu dianggap penting karena mereka mengurangi pesan dan overhead I/O dari protokol. Presume abort protocol meliputi X/Open XA standar dan telah diadopsi menjadi bagian standar ISO untuk Open Distributed Processing.

Karakteristik yang paling penting dari protokol 2PC adalah blocking nature. Kegagalan bisa terjadi ketika proses commit. Seperti yang telah didiskusikan, satu – satunya jalan untuk mendeteksi kegagalan tersebut adalah jika terjadi time-out ketika proses menunggu pesan. Ketika ini terjadi, proses (meliputi koordinator dan partisipan) yang time-outnya nengikuti termination protocol memutuskan apa yang harus dilakukan terhadap transaksi yang sedang berada di tengah proses commit. Non-blocking commit protocol adalah sebuah termination protocol yang dapat memutskan apa yang harus dilakukan terhadap transaksi yang mengalami kegagalan dibawah circumstance. Di kasus 2PC, jika kegagalan site terjadi pada koordinator site dan salah satu pertisipan site ketika koordinator sedang mengumpulkan votes dari partisipan, partisipan – partisipan tersebut tidak dapat memutuskan transaksi apa yang harus dijalankan pada dirinya sendiri, dan mereka harus di block sampai koordinator atau partisipan yang mengalami kegagalan bisa memperbaikinya. Selama waktu ini, lock yang diberikan kepada transaksi tersebut tidak dapat dijalankan, sehingga mengurangi availability dari database.

Dengan asumsi bahwa timeout dari partisipan terjadi setelah dia mengirimkan commit vote kepada koordinator, tetapi sebelum menerima pilihan final. Dalam kasus ini, partisipan berada dalam status ready, begitu juga yang terjadi pada termination protocol.Pertama, catat partisipan yang tidak bisa unilaterally mencapai keputusan termination.Sejak partisipan berada pada status ready, dia harus melakukan commit terhadap transaksi tersebut.Akan tetapi hal tersebut tidak dapat dirubah dan mengabortnya. Di lain pihak, it tidak dapat unilateracy memutuskan untuk commit transaksi sejak dimungkinkannya partisipant yang lain boleh memvoting untuk membatalkannya. Dalam kasus ini partisipant akan mengeblok sampai it dapat mempelajari dari seseorang (baik itu koordinator atau beberapa partisipant lainnya) the ultimate fate dari transaksi. Jika kita memperhatikan sebuah struktur komunikasi terpusat dimana partisipant tidak dapat berkomunikasi satu sama lain, berati partisipant kehabisan waktu untuk menunggu koordinator untuk melaporkan keputusan akhir dari transaksi. Sejak koordinator mengalami kegagalan, partisipant akan mengingatkan untuk diblok. Dalam kasus ini, tidak ada alasan termination protocol dapat didisain.

Jika partisipan dapat berkomunikasi satu sama lain, sebuah termination protocol terdistribusi dapat terus dikembangkan. Partisipan yang kehabisan waktu dapat meminta dengan mudah partisipan yang lain untuk membantunya mencapai sebuah keputusan. Jika selama termination semua partisipant merealisasikan bahwa hanya koordinator yang telah gagal, mereka dapat memilih koordinator baru yang dapat merestart proses yang dicommit. Akan tetapi, dalam kasus ini dimana partisipan dan koordinator mengalami kegagalan, maka masih mungkin untuk partisipan yang telah gagal menerima keputusan koordinator dan memberhentikan transaksi yang sesuai. Keputusan ini tidak diketahui oleh partisipan yang lain; Jika mereka memilih koordinator baru dan memproses maka lebih bahaya lagi mereka memutuskan transaksi yang berbeda di site yang gagal. Kasus di atas mencotohkan natural blocking dari 2 PC.

Kebalikan dari terminasi adalah recovery. Ketika site tidak bisa merecover dari kegagalan, aksi apa yang harus diambil untuk merecover database pada site untuk menjadi state yang konsisten. Ini adalah domain dari recoveri protokol terdistribusi. Mempertimbangkan sisi recoveri dari masalah yang didiskusikan diatas, koordinator tempat recoveri dan recoveri protokol harus mennentukan apa yang harus dilakukan dengan transaksi terdisitribusi yang eksekusinya telah dikoordinasikan. Kasus dibawah ini mungkin terjadi

1.      Koordinatornya gagal sebelum menginisialisasi porcedure commit. Oleh karena itu, koordinator akan memulai commit prosesnya sebelum recoveri.

2.      Koordinator gagal saat statusnya ready. Dalam kasus ini koordinator telah mengirim pesan prepare. Sebelum recovery koordinator akan merestart proses commit untuk transaksi dari awal dengan mengirimkan pesan prepare satu kali. Jika partisipannya sudah menterminasi transaksi, dapat membangun kembali koordinatornya. Jika mereka di blok mereka mengirim ulang pesan sebelumnya, dan meresume proses commit

3.      Koordinatornya gagal setelah ia membangun partisipan untuk masing masing keputusan global dan menterminasi transaksi tersebut. Oleh karena itu sebelum recoveri tidak perlu melakukan apapun.

7.5.2  FaseTigaTahap (3PC)

Kita telahmelihatbahwa 2PC bukanmerupakan protocol yang menghalangi, sejak 2PC memperbolehkanlokasiuntukmenghalangipadabeberapakeadaan.Sebagaicontoh, suatu proses yang times out setelahfasepemilihan, tetapisebelummenerimainstruksi global dari coordinator, tetapmenghalangapabilakomunikasi hanyadenganlokasi yang hampersamadantidakacuhpadakeputusan yang global. Kemungkinandarimenghalangiterjadidalampraktekadalahcukupjarangdibandingkansistem yang menggunakan 2PC.Bagaimanapun, adasuatu alternative protocol yang tidakterhalang, yang disebutfasetigatahap (3PC), yang telahdiusulkan (Skeen, 1981).Fasetigatahaptidakpernahterhalangiolehkesalahanpadasuatu, kecualipadakesalahandarisemualokasi.Kesalahankomunikasi, bagaimanapunmerupakansuatuhasildaribeberapalokasi yang berlainan yang meraihkeputusan yang berbeda, dengandemikianmelanggarvalensidaritindakan global.Protokolmemerlukanbahwa:

-          Tidakadapartisijaringan yang dapatterjadi

-          Sedikitnyaadasatulokasi yang harusselaluada

-          Padakebanyakanlokasi K dapatgagalsecarasimultan (disebutsebagaiK-resilent)

Dasardari 3PC adalahuntukmerubahperiode yang tidaktentukpadapesertasehinggatelahmelakukanpemilihandanmenungguuntukpembatalan global ataupersetujuan global darikoordinator.Fasetiga phase memperkenalkantahap yang ketiga, yang disebut pre-commit, antarapemilihandanpenentuan global. Dalammenerima seluruhpilihandaripeserta, coordinatormengirimkanpesan pre-commit.Peserta, yang menerima pre-commit yang global mengetahuibahwasemuapeserta yang lain sudahmemilihpilihan, dankemudianpadawaktunyapesertaitusendiri yang akanmenyetujui, kecualitidakberhasil. Setiappesertamengakuibagiandaripesan pre-commit, danketikacoordinatormenerimasemuapengakuan, Akan dibahaspersetujuan global.Sebuahpembatalanpilihandaripesertadiaturdalamcara yang samaseperti 2PC.

Keduanya, baikcoordinatordanpeserta, masihmempunyaiwaktuuntukmenunggu, tetapiGambaranpentingadalahbahwasemua proses operasisudahdiinformasikanpadapenentuan global untukmenyetujuidaripesan pre-commit utamanyapadamenyetujui proses pertama, dankemudianbertindakmasing-masingdalamhalkesalahan.