Както при всички неща, свързани с производителността, отговорът е:зависи. По-конкретно, зависи от това как точно използвате драйвера.
Разходите за транзакционно взаимодействие с база данни се разделят грубо на:режийни разходи за сложност на кода, комуникационни разходи, обработка на sql и I/O диск.
Комуникационните разходи се различават донякъде между XA и не-XA случаите. При равни други условия, XA транзакцията носи малко повече разходи тук, тъй като изисква повече двупосочни пътувания до db. За транзакция, която не е XA в режим на ръчно записване, цената е поне две извиквания:sql операция(и) и комит. В случая XA това е начало, sql операция(и), край, подготовка и ангажимент. За вашия специфичен случай на използване, който автоматично ще оптимизира за стартиране, sql операция(и), край, подготовка. Не всички обаждания са с еднаква цена:данните, преместени в набора от резултати, обикновено ще доминират. В LAN цената на допълнителните двупосочни пътувания обикновено не е значителна.
Имайте предвид обаче, че има някои интересни проблеми, които дебнат непредпазливите. Например, някои драйвери не поддържат кеширане на подготвени изрази в режим XA, което означава, че използването на XA носи допълнителните разходи за повторно анализиране на SQL при всяко извикване или изисква да използвате отделен пул от оператори отгоре на драйвера. Докато става въпрос за пуловете, правилното обединяване на XA връзки е малко по-сложно от обединяването на не-XA, така че в зависимост от реализацията на пула за връзки може да видите и лек удар и там. Някои ORM рамки са особено уязвими към режийни разходи за обединяване на връзки, ако използват агресивно освобождаване на връзка и повторно придобиване в рамките на обхвата на транзакцията. Ако е възможно, конфигурирайте да вземете и задържите връзка за целия живот на tx, вместо да удряте пула няколко пъти.
С предупреждението, споменато по-рано по отношение на кеширането на подготвени оператори, няма съществена разлика в цената на обработката на sql между XA и non-XA tx. Има обаче малка разлика в използването на ресурсите на db сървъра:в някои случаи може да е възможно сървърът да освободи ресурси по-рано в случай, който не е XA. Транзакциите обаче обикновено са достатъчно кратки, така че това не е важно съображение.
Сега разглеждаме дискови входно/изходни разходи. Тук сме загрижени за I/O, предизвикани от XA протокола, а не от SQL, използван за бизнес логиката, тъй като последният е непроменен и в двата случая. За транзакциите само за четене ситуацията е проста:разумният мениджър на db и tx няма да прави никакви записи в дневник, така че няма излишни разходи. За случаите на запис, същото важи, когато db е единственият включен ресурс, поради еднофазовата оптимизация на записване на XA. За случая 2PC всеки db сървър или друг мениджър на ресурси се нуждае от две записи на диск вместо този, използван в случаи, които не са XA, а tx мениджърът също се нуждае от две. Благодарение на бавността на дисковото съхранение това е доминиращият източник на режийни разходи в XA спрямо не-XA.
Няколко параграфа назад споменах сложността на кода. XA изисква малко повече изпълнение на код, отколкото не-XA. В повечето случаи сложността е заровена в мениджъра на транзакции, въпреки че, разбира се, можете да управлявате XA директно, ако предпочитате. Цената е най-вече тривиална, при спазване на вече споменатите предупреждения. Освен ако не използвате особено лош мениджър на транзакции, в този случай може да имате проблем. Случаят само за четене е особено интересен – доставчиците на мениджър на транзакции обикновено полагат усилията си за оптимизиране на дисковия I/O код, докато спорът за заключване е по-важен проблем за случаите на използване само за четене, особено при силно конкурентни системи.
Имайте предвид също, че сложността на кода в tx мениджъра е нещо като червена херинга в архитектурите, включващи сървър на приложения или друг стандартен доставчик на мениджър на транзакции, тъй като те обикновено използват почти същия код за XA и не-XA координация на транзакциите. В случаи, които не са XA, за да пропуснете изцяло tx мениджъра, обикновено трябва да кажете на сървъра на приложенията / рамката да третира връзката като не-транзакционна и след това да управлявате комитирането директно чрез JDBC.
И така, обобщениета е:Цената на вашите sql заявки ще доминира във времето за транзакция само за четене, независимо от избора XA/non-XA , освен ако не объркате нещо в конфигурацията или не извършите особено тривиални sql операции във всеки tx, като последното е знак, че вашата бизнес логика вероятно може да използва известно преструктуриране, за да промени съотношението на режийните разходи за управление на tx към бизнес логиката във всеки tx.
За случаите само за четене важи обичайният съвет за агностика на протокола за транзакции:помислете за кеш на второ ниво на ниво информация за транзакциите в ORM решение, вместо да удряте DB всеки път. Ако не успеете, настройте sql, след което увеличете кеша на буфера на db, докато видите 90%+ процент на попадане или не увеличите максимално RAM слотовете на сървъра, което от двете настъпи първо. Безпокойте за XA спрямо не-XA само след като сте направили това и установите, че нещата все още са твърде бавни.
