Wie bei allen leistungsbezogenen Dingen lautet die Antwort:Es kommt darauf an. Insbesondere hängt es davon ab, wie Sie den Treiber verwenden.
Die Kosten für die transaktionale Interaktion mit einer Datenbank werden grob unterteilt in:Overhead für Codekomplexität, Overhead für Kommunikation, SQL-Verarbeitung und Festplatten-I/O.
Der Kommunikationsaufwand unterscheidet sich etwas zwischen den XA- und Nicht-XA-Fällen. Wenn alles andere gleich ist, verursacht eine XA-Transaktion hier etwas mehr Kosten, da mehr Roundtrips zur Datenbank erforderlich sind. Für eine Nicht-XA-Transaktion im manuellen Festschreibungsmodus betragen die Kosten mindestens zwei Aufrufe:die SQL-Operation(en) und die Festschreibung. Im XA-Fall sind es Start, SQL-Operation(en), Ende, Vorbereitung und Commit. Für Ihren spezifischen Anwendungsfall, der automatisch zum Starten, SQL-Vorgang(en), Beenden und Vorbereiten optimiert wird. Nicht alle Aufrufe sind gleich teuer:Die in der Ergebnismenge verschobenen Daten dominieren normalerweise. Auf einem LAN sind die Kosten für die zusätzlichen Hin- und Rückfahrten normalerweise nicht signifikant.
Beachten Sie jedoch, dass einige interessante Fallstricke auf die Unvorsichtigen warten. Beispielsweise unterstützen einige Treiber das Zwischenspeichern vorbereiteter Anweisungen im XA-Modus nicht, was bedeutet, dass die XA-Nutzung den zusätzlichen Overhead mit sich bringt, das SQL bei jedem Aufruf neu zu analysieren, oder dass Sie einen separaten Anweisungspool zusätzlich zum Treiber verwenden müssen. Apropos Pools:Das korrekte Poolen von XA-Verbindungen ist etwas komplexer als das Poolen von Nicht-XA-Verbindungen, sodass Sie je nach Implementierung des Verbindungspools möglicherweise auch dort einen leichten Treffer sehen. Einige ORM-Frameworks sind besonders anfällig für Verbindungspooling-Overhead, wenn sie aggressive Verbindungsfreigaben und -erneuerungen innerhalb des Transaktionsbereichs verwenden. Konfigurieren Sie nach Möglichkeit so, dass eine Verbindung für die Lebensdauer des TX aufgebaut und gehalten wird, anstatt mehrmals auf den Pool zu treffen.
Mit der zuvor erwähnten Einschränkung bezüglich des Zwischenspeicherns von vorbereiteten Anweisungen gibt es keinen wesentlichen Unterschied in den Kosten der SQL-Handhabung zwischen XA- und Nicht-XA-Tx. Es gibt jedoch einen kleinen Unterschied zur Ressourcennutzung auf dem db-Server:In einigen Fällen kann es für den Server möglich sein, Ressourcen im Nicht-XA-Fall früher freizugeben. Transaktionen sind jedoch normalerweise kurz genug, dass dies keine wesentliche Überlegung darstellt.
Jetzt betrachten wir den Festplatten-I/O-Overhead. Hier geht es um E/A, die durch das XA-Protokoll verursacht werden, und nicht um das für die Geschäftslogik verwendete SQL, da letzteres in beiden Fällen unverändert bleibt. Bei Nur-Lese-Transaktionen ist die Situation einfach:Ein vernünftiger DB- und TX-Manager führt keine Protokollschreibvorgänge durch, sodass kein Overhead entsteht. Für Schreibfälle gilt das gleiche, wo die db die einzige betroffene Ressource ist, aufgrund der einphasigen Commit-Optimierung von XA. Für den 2PC-Fall benötigt jeder DB-Server oder andere Ressourcenmanager zwei Schreibvorgänge auf der Festplatte anstelle des einen, der in Nicht-XA-Fällen verwendet wird, und der TX-Manager benötigt ebenfalls zwei. Dank der Langsamkeit des Plattenspeichers ist dies die dominierende Quelle des Leistungs-Overheads in XA im Vergleich zu Nicht-XA.
Einige Absätze zurück habe ich die Komplexität des Codes erwähnt. XA erfordert etwas mehr Codeausführung als Nicht-XA. In den meisten Fällen ist die Komplexität im Transaktionsmanager begraben, obwohl Sie XA natürlich auch direkt steuern können, wenn Sie dies bevorzugen. Die Kosten sind meist trivial, vorbehaltlich der bereits erwähnten Einschränkungen. Es sei denn, Sie verwenden einen besonders schlechten Transaktionsmanager, in diesem Fall könnten Sie ein Problem haben. Der Fall des Nur-Lesens ist besonders interessant – Anbieter von Transaktionsmanagern investieren normalerweise ihre Optimierungsbemühungen in den Festplatten-E/A-Code, während Sperrkonflikte ein bedeutenderes Problem für Anwendungsfälle des Nur-Lesens sind, insbesondere auf Systemen mit hoher Parallelität.
Beachten Sie auch, dass die Codekomplexität im tx-Manager in Architekturen mit einem App-Server oder anderen Standard-Transaktionsmanageranbietern so etwas wie ein Ablenkungsmanöver ist, da diese normalerweise den gleichen Code für die XA- und Nicht-XA-Transaktionskoordination verwenden. Um den tx-Manager in Nicht-XA-Fällen vollständig zu überspringen, müssen Sie normalerweise den App-Server / das Framework anweisen, die Verbindung als nicht transaktional zu behandeln, und dann den Commit direkt über JDBC steuern.
Also die Zusammenfassung ist:Die Kosten Ihrer SQL-Abfragen werden die Nur-Lese-Transaktionszeit dominieren, unabhängig von der XA/Nicht-XA-Wahl , es sei denn, Sie vermasseln etwas in der Konfiguration oder führen besonders triviale SQL-Operationen in jedem TX aus, wobei letzteres ein Zeichen dafür ist, dass Ihre Geschäftslogik wahrscheinlich eine Umstrukturierung gebrauchen könnte, um das Verhältnis von TX-Verwaltungsaufwand zu Geschäftslogik in jedem TX zu ändern.
Für Nur-Lese-Fälle gilt daher der übliche agnostische Ratschlag für Transaktionsprotokolle:Erwägen Sie einen transaktionsbewussten Second-Level-Cache in einer ORM-Lösung, anstatt jedes Mal auf die DB zuzugreifen. Wenn dies nicht der Fall ist, optimieren Sie die SQL und erhöhen Sie dann den Puffer-Cache der Datenbank, bis Sie eine Trefferrate von über 90 % sehen, oder Sie maximieren die RAM-Steckplätze des Servers, je nachdem, was zuerst eintritt. Machen Sie sich erst Gedanken über XA vs. Nicht-XA, wenn Sie das getan haben und feststellen, dass die Dinge immer noch zu langsam sind.
