Zoals met alles wat met prestaties te maken heeft, is het antwoord:het hangt ervan af. Het hangt er met name van af hoe u het stuurprogramma precies gebruikt.
De kosten van transactionele interactie met een database worden ruwweg onderverdeeld in:overhead voor codecomplexiteit, communicatie-overhead, sql-verwerking en schijf-I/O.
De communicatie-overhead verschilt enigszins tussen de XA- en niet-XA-gevallen. Als al het andere gelijk is, brengt een XA-transactie hier iets meer kosten met zich mee, omdat er meer retourvluchten naar de db nodig zijn. Voor een niet-XA-transactie in handmatige vastleggingsmodus zijn de kosten ten minste twee aanroepen:de sql-bewerking(en) en de vastlegging. In het XA-geval is het start, sql-bewerking(en), end, prepare en commit. Voor uw specifieke gebruiksgeval dat automatisch wordt geoptimaliseerd om te starten, sql-bewerking(en), te beëindigen, voor te bereiden. Niet alle oproepen zijn even duur:de gegevens die in de resultatenset worden verplaatst, zullen meestal domineren. Op een LAN zijn de kosten van de extra retourvluchten meestal niet significant.
Merk echter op dat er een aantal interessante valkuilen op de loer liggen voor de onoplettende. Sommige stuurprogramma's ondersteunen bijvoorbeeld geen caching van voorbereide instructies in de XA-modus, wat betekent dat XA-gebruik de extra overhead met zich meebrengt van het opnieuw parseren van de SQL bij elke aanroep, of vereist dat u een aparte instructiegroep gebruikt bovenop het stuurprogramma. Over het onderwerp pools gesproken, het correct poolen van XA-verbindingen is iets ingewikkelder dan het poolen van niet-XA-verbindingen, dus afhankelijk van de implementatie van de verbindingspool kun je daar ook een kleine hit zien. Sommige ORM-frameworks zijn bijzonder kwetsbaar voor overhead voor verbindingspooling als ze agressieve verbindingsvrijgave gebruiken en opnieuw verwerven binnen het transactiebereik. Configureer indien mogelijk om een verbinding te pakken en vast te houden voor de levensduur van de tx in plaats van meerdere keren naar de pool te gaan.
Met het eerder genoemde voorbehoud met betrekking tot het cachen van voorbereide verklaringen, is er geen wezenlijk verschil in de kosten van de sql-verwerking tussen XA en niet-XA tx. Er is echter een klein verschil met het gebruik van bronnen op de db-server:in sommige gevallen kan het voor de server mogelijk zijn om bronnen eerder vrij te geven in het niet-XA-geval. Transacties zijn normaal gesproken echter zo kort dat dit geen belangrijke overweging is.
Nu beschouwen we schijf-I/O-overhead. Hier hebben we te maken met I/O veroorzaakt door het XA-protocol in plaats van de SQL die wordt gebruikt voor de bedrijfslogica, aangezien de laatste in beide gevallen ongewijzigd blijft. Voor alleen-lezen transacties is de situatie eenvoudig:een verstandige db en tx manager zal geen log-writes doen, dus er is geen overhead. Voor schrijfsituaties geldt hetzelfde waar de db de enige betrokken bron is, dankzij XA's één-fase commit-optimalisatie. Voor het 2PC-geval heeft elke db-server of andere resourcemanager twee schijfschrijfbewerkingen nodig in plaats van degene die in niet-XA-gevallen wordt gebruikt, en de tx-manager heeft er eveneens twee nodig. Dankzij de traagheid van schijfopslag is dit de dominante bron van prestatieoverhead in XA versus niet-XA.
Enkele paragrafen terug noemde ik codecomplexiteit. XA vereist iets meer code-uitvoering dan niet-XA. In de meeste gevallen ligt de complexiteit begraven in de transactiemanager, hoewel u XA natuurlijk rechtstreeks kunt besturen als u dat wilt. De kosten zijn meestal triviaal, behoudens de reeds genoemde kanttekeningen. Tenzij u een bijzonder slechte transactiebeheerder gebruikt, in welk geval u mogelijk een probleem hebt. Het alleen-lezen geval is bijzonder interessant - aanbieders van transactiebeheer zetten hun optimalisatie-inspanningen meestal in de schijf-I/O-code, terwijl vergrendelingsconflict een belangrijker probleem is voor alleen-lezen-gebruiksgevallen, met name op zeer gelijktijdige systemen.
Merk ook op dat codecomplexiteit in de tx-manager een soort rode haring is in architecturen met een app-server of andere standaard transactiemanager-provider, omdat deze meestal vrijwel dezelfde code gebruiken voor XA- en niet-XA-transactiecoördinatie. In niet-XA-gevallen, om de tx-manager volledig te missen, moet je de app-server / het framework meestal vertellen om de verbinding als niet-transactioneel te behandelen en de commit vervolgens rechtstreeks aansturen met JDBC.
Dus de samenvatting is:De kosten van uw SQL-query's zullen de alleen-lezen transactietijd domineren, ongeacht de keuze voor XA/niet-XA , tenzij u iets in de configuratie verknoeit of bijzonder triviale sql-bewerkingen uitvoert in elke tx, waarbij het laatste een teken is dat uw bedrijfslogica waarschijnlijk wat herstructurering zou kunnen gebruiken om de verhouding tussen overhead voor tx-beheer en bedrijfslogica in elke tx te veranderen.
Voor alleen-lezen gevallen is daarom het gebruikelijke agnostische advies van het transactieprotocol van toepassing:overweeg een transactiebewust niveau cache op het tweede niveau in een ORM-oplossing in plaats van elke keer de DB te raken. Als dat niet lukt, stemt u de sql af en verhoogt u vervolgens de buffercache van de db totdat u een hitrate van 90% of meer ziet of dat u de RAM-slots van de server maximaal benut, afhankelijk van wat zich het eerst voordoet. Maak je pas zorgen over XA versus niet-XA als je dat eenmaal hebt gedaan en ontdekt dat de dingen nog steeds te traag zijn.