Zum Hauptinhalt springen
Transaktionsverarbeitung

Begrenzung der Transaktionsverarbeitung z. B. beim Importieren großer XML

Lenka Haringerová avatar
Verfasst von Lenka Haringerová
Vor über 2 Jahren aktualisiert

Diese Seite beschreibt eine erweiterte Variante des XML-Imports, die bei unsachgemäßer Anwendung zu Dateninkonsistenzen führen kann!

Standardmäßig wird jeder Import als eine einzige Datenbanktransaktion durchgeführt - es wird also entweder alles oder nichts gespeichert.

Dies ist in der Regel das gewünschte Verhalten und es gibt normalerweise keinen Grund, etwas daran zu ändern. Es kann jedoch Situationen geben, in denen das transaktionale Verhalten nicht notwendig ist, dann kann das atomic Attribut verwendet werden, um dieses Verhalten zu ändern.

<?xml version="1.0"?>
<winstrom version="1.0" atomic="false">
<faktura-vydana>
<id>code:123</id> ...
<polozkyFaktury>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
</polozkyFaktury>
</faktura-vydana>
<faktura-vydana>
<id>code:456</id> ...
<polozkyFaktury>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
</polozkyFaktury>
</faktura-vydana>
</winstrom>

Wenn Sie das Attribut " atomic" auf "false" setzen, wird jeder Datensatz in einer separaten Transaktion importiert. Im obigen Beispiel gibt es also zwei Datenbanktransaktionen, eine für Rechnung 123 und eine für Rechnung 456. Die Artikel sind Teil der Rechnung und werden daher in der gleichen Transaktion wie die Rechnung selbst importiert.

Was ist der Vorteil davon? Wenn Sie große XML-Dateien mit vielen Datensätzen importieren, dauert die Transaktion sehr lange und es müssen viele Informationen im Speicher gehalten werden. Beides hat einen negativen Einfluss auf die Leistung. Wenn aber jeder Datensatz separat ist und es Sie nicht stört, dass das Speichern eines dieser Datensätze fehlschlägt (z. B. wenn Sie den Import regelmäßig wiederholen und/oder bei Problemen manuell eingreifen können), können Sie den Speicherbedarf des Imports erheblich reduzieren.

Bei wirklich großen Importen ist der Speicherbedarf für die Speicherung der noch nicht gesicherten Daten so groß, dass ein erheblicher Teil der CPU-Zeit durch den Garbage Collector in Anspruch genommen wird (dies kann z. B. mit dem Tool jconsole überwacht werden, das standardmäßig Bestandteil der JDK-Entwicklungsumgebung ist). Im Modus atomic="false" kann der Zeitverbrauch in einem solchen Fall deutlich reduziert werden.

Hat dies deine Frage beantwortet?