NServiceBus и DTC

Използвам дистрибутора в NServiceBus и се натъкнах на стената на невежество по отношение на DTC. Използвал съм DTC само веднъж, може би два пъти преди, когато правех неща в процеси и не много, така че съм много начинаещ с цялата концепция на DTC.

Question:
To ensure durable messaging with NSB, is it absolutely necessary to use DTC's?

Причината, поради която питам, е, че бих очаквал NSB да може да открие всяко изключение, да речем манипулатор, и следователно да реагира на грешката, като не премахва съобщението от опашката. Следователно няма нужда от DTC. Това, разбира се, би означавало, че всеки достъп до база данни или външна услуга в манипулатора ще изисква от програмиста да извърши нейни/свои собствени връщания назад и т.н. И поради тази причина DTC наистина изглежда като най-добрия начин. Така че аз съм за DTC (ако ги разбирам правилно), тъй като от моя гледна точка те гарантират, че съобщенията никога не се губят от опашките и обработката на съобщения никога няма да бъде повредена, стига манипулаторите да са внедрени правилно и други външни услуги да участват в DTC .

Но не съм сигурен, особено след като един уважаван човек от екипа по поддръжка на сървъра използва изречението „DTC ще ви причини цяла болка!“, когато пуснах идеята за активиране на DTC на сървъра на базата данни от него... Но той все още не е представил аргументи защо изпитвам толкова много болка с DTC... :/.

Може ли някой с добро разбиране на DTC и NSB, моля, помогнете ми да изясня дали напълно не разбирам DTC и дали има някакъв голям капан, който напълно съм пропуснал с DTC?

Поздрави


person Christian Mikkelsen    schedule 08.03.2013    source източник


Отговори (1)


Дистрибуторът на NServiceBus и използването на DTC в NServiceBus нямат нищо общо едно с друго. DTC ще се използва от NServiceBus, независимо дали използвате дистрибутора или не.

NSB дистрибуторските работници (и дори отделните работни нишки в една кутия, когато NSB дистрибуторът не се използва) не се включват един друг в разпределени транзакции. Позволете ми да повторя, никога няма да видите две работни нишки на NSB в една DTC транзакция. Всяка работна нишка стартира транзакция срещу локална опашка и след това добавя (вероятно отдалечена) база данни към транзакцията (което я прави разпределена)

Има хубава илюстрация на концепцията тук

Не мисля, че пропускате големи клопки. Просто бих разделил двете концепции, NSB дистрибутор и как разпределените транзакции се използват от NSB

person Chris Bednarski    schedule 09.03.2013
comment
Благодаря ти. Но сега ми е любопитно защо имате опцията да деактивирате DTC с IsTransactional(false). Какво може да спечелите, като го деактивирате? Производителност? - person Christian Mikkelsen; 09.03.2013
comment
IsTransactional казва на nsb да не включва операцията за получаване в tx. Това означава, че съобщението се губи, ако нещо се обърка във вашия манипулатор на съобщения. Nsb 3 има опция за конфигуриране SupressDtc, която все още използва tx, но избягва dtc. Въпреки това основните последици от пропускането на dtc са в това как трябва да внедрите вашата бизнес логика. Вероятно трябва да проучите това, преди да се обадите? - person Andreas Öhlund; 09.03.2013
comment
Така че използването на SupressDTC все още ще гарантира липса на загуба на съобщение, ако манипулаторът се провали, но цената е, че манипулаторът след това трябва да обработва всички връщания към DB транзакция и т.н. ръчно, например? - person Christian Mikkelsen; 09.03.2013
comment
да DTC ви спестява сами да пишете логиката за дедупликация - person Chris Bednarski; 09.03.2013