Som med allt relaterat till prestanda är svaret:det beror på. Specifikt beror det på exakt hur du använder drivrutinen.
Kostnaden för att interagera transaktionellt med en databas är grovt uppdelad i:kodkomplexitetsoverhead, kommunikationsoverhead, sql-bearbetning och disk I/O.
Kommunikationsoverhead skiljer sig något mellan XA- och icke-XA-fallen. Allt annat lika kostar en XA-transaktion lite mer här eftersom det kräver fler tur och returresor till db. För en icke-XA-transaktion i manuellt commit-läge är kostnaden minst två anrop:sql-operation(erna) och commit. I XA-fallet är det start, sql operation(er), end, prepare och commit. För ditt specifika användningsfall som automatiskt optimerar för att starta, sql-operationer, avsluta, förbereda. Alla samtal har inte samma kostnad:data som flyttas i resultatuppsättningen kommer vanligtvis att dominera. På ett LAN är kostnaden för ytterligare tur och retur vanligtvis inte betydande.
Observera dock att det finns några intressanta gotchas som lurar de oförsiktiga. Till exempel stöder vissa drivrutiner inte förberedd satscache i XA-läge, vilket innebär att XA-användning medför den extra overheaden av att analysera SQL på nytt vid varje anrop, eller kräver att du använder en separat satspool ovanpå drivrutinen. Även om det handlar om pooler, är det lite mer komplext att poola XA-anslutningar på rätt sätt än att poola icke-XA-anslutningar, så beroende på implementeringen av anslutningspoolen kan du se en liten träff där också. Vissa ORM-ramverk är särskilt sårbara för anslutningspooling om de använder aggressiv anslutningsfrigivning och återanskaffning inom transaktionsomfång. Om möjligt, konfigurera för att ta och hålla en anslutning under hela tx:ns livstid istället för att slå i poolen flera gånger.
Med den varning som nämnts tidigare angående cachelagring av förberedda uttalanden, finns det ingen väsentlig skillnad i kostnaden för sql-hanteringen mellan XA och icke-XA tx. Det finns dock en liten skillnad för resursanvändningen på db-servern:i vissa fall kan det vara möjligt för servern att släppa resurser tidigare i icke-XA-fallet. Transaktioner är dock normalt tillräckligt korta för att detta inte är en viktig faktor.
Nu överväger vi disk I/O overhead. Här handlar det om I/O som orsakas av XA-protokollet snarare än SQL som används för affärslogiken, eftersom den senare är oförändrad i båda fallen. För skrivskyddade transaktioner är situationen enkel:en vettig db- och tx-hanterare kommer inte att göra några loggskrivningar, så det finns ingen overhead. För skrivfall gäller samma sak där db är den enda inblandade resursen, på grund av XAs enfas-commit-optimering. För 2PC-fallet behöver varje db-server eller annan resurshanterare två diskskrivningar istället för den som används i icke-XA-fall, och tx-hanteraren behöver likaså två. Tack vare den långsamma disklagringen är detta den dominerande källan till prestandaoverhead i XA kontra icke-XA.
Flera stycken tillbaka nämnde jag kodkomplexitet. XA kräver något mer kodexekvering än icke-XA. I de flesta fall ligger komplexiteten begravd i transaktionshanteraren, även om du självklart kan köra XA direkt om du föredrar det. Kostnaden är mestadels trivial, med förbehåll för de varningar som redan nämnts. Om du inte använder en särskilt dålig transaktionshanterare, i vilket fall du kan ha ett problem. Det skrivskyddade fallet är särskilt intressant - leverantörer av transaktionshanterare lägger vanligtvis sina optimeringsansträngningar på diskens I/O-kod, medan låskonflikter är en viktigare fråga för skrivskyddade användningsfall, särskilt på mycket samtidiga system.
Observera också att kodkomplexitet i tx-hanteraren är något av en röd tråd i arkitekturer med en appserver eller annan standardleverantör av transaktionshanterare, eftersom dessa vanligtvis använder ungefär samma kod för XA- och icke-XA-transaktionskoordinering. I icke-XA-fall, för att missa TX-hanteraren helt och hållet, måste du vanligtvis säga till appservern/ramverket att behandla anslutningen som icke-transaktionell och sedan driva commit direkt med JDBC.
Så sammanfattningen är:Kostnaden för dina sql-frågor kommer att dominera den skrivskyddade transaktionstiden oavsett XA/icke-XA-val , såvida du inte förstör något i konfigurationen eller gör särskilt triviala sql-operationer i varje tx, det senare är ett tecken på att din affärslogik förmodligen skulle kunna använda en viss omstrukturering för att ändra förhållandet mellan TX-hanteringsoverhead och affärslogik i varje tx.
För skrivskyddade fall gäller därför det vanliga agnostiska råd för transaktionsprotokoll:överväg en transaktionsmedveten nivå på andra nivån cache i en ORM-lösning snarare än att slå DB varje gång. Om det misslyckas, ställ in sql, och öka sedan db:s buffertcache tills du ser en träfffrekvens på 90%+ eller så maxar du serverns RAM-platser, beroende på vilket som kommer först. Oroa dig bara för XA kontra icke-XA när du har gjort det och upptäckt att saker fortfarande går för långsamt.