Dar in felul asta introduci artificial puncte de failure. Daca in 'mesh' un nod e cazut, el numai primeste updaturile pina nu revine online. In cerc, daca un nod e cazut blocheaza pe toata lumea eventual (toate updaturile se opresc la el).

Ca sa intzeleg mai bine, ceea ce propui tu este asa: S1 primeste un update. In trigger el se conecteaza la un linked server S2, promoveaza tranzactia locala in DTC, apoi updateaza remote S2. Batch-ul din S1 este blocat asteptind rezultatul de la linked server. S2 face update, apoi ruleaza trigger-ul sau. In trigger se conecteaza la linked server S3, adauga si pe S3 la DTC-ul care-l are cu S1 face update-ul pe S3. Batchul de pe S1 este acum blocat asteptind batch-ul de pe S2 care este acuma blocat asteptind batch-ul de pe S3. Si asa mai departe. Sn in trigger-ul detecteaza ca update-ul vine de la S1 si numai apeleaza S1 . Asta pentru, dupa cum sper ca stii, daca Sn se conecteaza la S1 va incerca sa enroleze o noua sesiune in tranzactia existenta, rezultind in eroarea 3910 "Transaction context in use by another session".
Deci toate serverele, de la S1 la Sn sin acuma enrolate intr-o tranzactie distribuita coordonata de MSDTC de pe S1 (care a inceput-o). Fiecare server este blocat asteptind-ul pe urmatorul sa termine batch-ul. Sn ruleaza trigger-ul de update (fara sa se conecteze la S1, am explicat de ce), apoi Sn-1 poate continua si tot asa pina controlul se intoarce la S1. Acuma S1 poate termina trigger-ul, statement-ul care a facut update-ul in sfirsit poate sa se termine, si eventula tranzactia sa comita. S1 cere DTC-ului sa  comita, DTC-ul face magia in doi pasi si toate serverele comit.

---

http://rusanu.com