Som med alle ting relateret til ydeevne, er svaret:det afhænger. Specifikt afhænger det af præcis, hvordan du bruger driveren.
Omkostningerne ved at interagere transaktionelt med en database er groft opdelt i:kodekompleksitetsoverhead, kommunikationsoverhead, sql-behandling og disk I/O.
Kommunikationsoverhead adskiller sig en del mellem XA- og ikke-XA-tilfældene. Alt andet lige koster en XA transaktion lidt flere omkostninger her, da det kræver flere rundrejser til db. For en ikke-XA-transaktion i manuel commit-tilstand er prisen mindst to opkald:sql-operation(erne) og commit. I XA-tilfældet er det start, sql-operation(er), afslutning, forberedelse og commit. Til din specifikke brugssag, der automatisk vil optimere for at starte, sql operation(er), afslutte, forberede. Ikke alle opkald har samme pris:de data, der flyttes i resultatsættet, vil normalt dominere. På et LAN er omkostningerne ved de ekstra rundrejser normalt ikke væsentlige.
Bemærk dog, at der er nogle interessante gotchas, der lurer på lur for de uforsigtige. Nogle drivere understøtter f.eks. ikke forberedt sætningscache i XA-tilstand, hvilket betyder, at XA-brug medfører den ekstra overhead ved genparsing af SQL'en ved hvert kald, eller kræver, at du bruger en separat sætningspulje oven på driveren. Mens det drejer sig om emnet pools, er korrekt pooling af XA-forbindelser lidt mere kompleks end pooling af ikke-XA-forbindelser, så afhængigt af forbindelsespuljens implementering kan du også se et lille hit der. Nogle ORM-frameworks er særligt sårbare over for forbindelsespooling-overhead, hvis de bruger aggressiv forbindelsesfrigivelse og genanskaffelse inden for transaktionsomfang. Hvis det er muligt, konfigurer til at gribe og holde en forbindelse i hele tx'ens levetid i stedet for at ramme poolen flere gange.
Med den tidligere nævnte advarsel vedrørende cachelagring af forberedte erklæringer, er der ingen væsentlig forskel i omkostningerne ved sql-håndteringen mellem XA og ikke-XA tx. Der er dog en lille forskel på ressourceforbruget på db-serveren:i nogle tilfælde kan det være muligt for serveren at frigive ressourcer hurtigere i tilfældet uden for XA. Transaktioner er dog normalt korte nok til, at dette ikke er en væsentlig overvejelse.
Nu overvejer vi disk I/O overhead. Her er vi bekymrede for I/O forårsaget af XA-protokollen snarere end den SQL, der bruges til forretningslogikken, da sidstnævnte er uændret i begge tilfælde. For skrivebeskyttede transaktioner er situationen enkel:en fornuftig db- og tx-manager vil ikke lave nogen logskrivning, så der er ingen overhead. For skrivesager gælder det samme, hvor db'en er den eneste involverede ressource, på grund af XA's one phase commit optimering. Til 2PC-sagen har hver db-server eller anden ressourcemanager brug for to diskskrivninger i stedet for den, der bruges i ikke-XA-tilfælde, og tx-manageren har ligeledes brug for to. Takket være den langsomme disklagring er dette den dominerende kilde til ydeevneomkostninger i XA vs. ikke-XA.
Flere afsnit tilbage nævnte jeg kodekompleksitet. XA kræver lidt mere kodeudførelse end ikke-XA. I de fleste tilfælde er kompleksiteten begravet i transaktionshåndteringen, selvom du selvfølgelig kan køre XA direkte, hvis du foretrækker det. Omkostningerne er for det meste trivielle, med forbehold af de allerede nævnte forbehold. Medmindre du bruger en særlig dårlig transaktionsadministrator, i hvilket tilfælde du kan have et problem. Den skrivebeskyttede sag er særlig interessant - udbydere af transaktionshåndtering lægger normalt deres optimeringsindsats i disk I/O-koden, hvorimod låsestrid er et mere væsentligt problem for skrivebeskyttede brugssager, især på meget samtidige systemer.
Bemærk også, at kodekompleksitet i tx-manageren er noget af en rød tråd i arkitekturer med en app-server eller en anden standardtransaktionsmanagerudbyder, da disse normalt bruger meget den samme kode til XA- og ikke-XA-transaktionskoordinering. I ikke-XA-tilfælde skal du for helt at gå glip af tx-manageren typisk bede appserveren/rammeværket om at behandle forbindelsen som ikke-transaktionel og derefter køre commit direkte ved hjælp af JDBC.
Så resuméet er:Omkostningerne ved dine sql-forespørgsler kommer til at dominere den skrivebeskyttede transaktionstid uanset XA/ikke-XA-valget , medmindre du roder noget i konfigurationen eller laver særligt trivielle sql-operationer i hver tx, hvor sidstnævnte er et tegn på, at din forretningslogik sandsynligvis kunne bruge nogle omstruktureringer til at ændre forholdet mellem tx-administration overhead og forretningslogik i hver tx.
For skrivebeskyttede tilfælde gælder derfor det sædvanlige agnostiske råd for transaktionsprotokol:overvej en transaktionsbevidst cache på andet niveau i en ORM-løsning i stedet for at ramme DB hver gang. Hvis det ikke er tilfældet, skal du tune sql'en, og derefter øge db's buffer-cache, indtil du ser en 90%+ hitrate, eller du maksimerer serverens RAM-slots, alt efter hvad der kommer først. Bare bekymre dig om XA vs. ikke-XA, når du har gjort det og fundet ud af, at tingene stadig går for langsomt.