Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Transaktionseinleitende Anweisungen in CLI-Aufrufen

Die meisten CLI-Aufrufe enthalten transaktionseinleitende SQL-Anweisungen. Mit Ausnahme von SQL_BLOB_CLS_REF werden in allen CLI-Aufrufen SQL-Anweisungen zur Datenmanipulation (abfragen, ändern) aufgerufen.

In einer SQL-Transaktion dürfen entweder nur SQL-Anweisungen zur Datenmanipulation oder nur SQL-Anweisungen zur Schemadefinition und -verwaltung ausgeführt werden (siehe „Anweisungen innerhalb von Transaktionen"). Aus diesem Grund können CLI-Aufrufe in einer SQL-Transaktion nicht erfolgreich durchgeführt werden, wenn auch SQL-Anweisungen zur Schemadefinition und -verwaltung in dieser Transaktion aufgerufen werden.

Isolationslevel

Mit dem Isolationslevel kann die Parallelität der Transaktionen beeinflusst werden. Die einzelnen Level und die möglichen Phänomene bei konkurrierenden Transaktionen sind im Abschnitt „SET TRANSACTION - Transaktionseigenschaften festlegen" beschrieben. Für die Bearbeitung von BLOB-Objekten mit CLI-Funktionen ergeben sich folgende Auswirkungen:

  • Wird ein BLOB-Wert in einer Transaktion mit dem Isolationslevel SERIALIZABLE oder REPEATABLE READ gelesen, so werden Änderungen durch konkurrierende Transaktionen so lange verzögert, bis das Lesen des Wertes abgeschlossen ist. Änderungen konkurrierender Transaktionen sind also entweder vollständig sichtbar oder unsichtbar. Das Phänomen phantom kann hier nicht auftreten, da REF-Werte nicht wieder verwendet werden.

  • Wird ein BLOB-Wert in einer Transaktion mit dem Isolationslevel READ COMMITTED oder READ UNCOMMITTED gelesen, so kann er innerhalb der Transaktion durch konkurrierende Transaktionen geändert werden. Es ist dann möglich, dass teilweise alte und teilweise neue Werte gelesen werden. Es könnte sogar vorkommen, dass während des Lesens zweier Stücke eines BLOB-Werts das BLOB-Objekt gelöscht wird und danach durch ein anderes mit der gleichen Objektnummer ersetzt wird. Am Attribut UPDATED können Sie erkennen, wann das Objekt zuletzt geändert wurde und somit sicherstellen, dass es sich noch um dasselbe handelt.

Konsistenz bei Updates

Der BLOB-Wert eines BLOB-Objekts wird in mehreren Zeilen einer BLOB-Tabelle gespeichert. Zum Ersetzen eines existierenden BLOB-Werts ist deshalb im Allgemeinen mehr als eine DML-Anweisung notwendig. Das Ändern eines BLOB-Objekts ist deshalb keine atomare Operation.

Aus diesem Grund kann es vorkommen, dass das Ändern nur teilweise erfolgreich ist. Beispielsweise kann beim Schreiben des neuen Werts eines BLOB-Objekts der erste Aufruf von BLOB_VAL_STOW (siehe "SQL_BLOB_VAL_STOW - SQLbvst") erfolgreich sein, der zweite aber nicht. In solchen Fällen sollten Sie mit ROLLBACK alle Änderungen zurücksetzen.

Das Ändern der Attribute von BLOB-Objekten und das Löschen von BLOB-Objekten sind jedoch atomare Operationen. Schlagen sie fehl, wird der ursprüngliche Zustand hergestellt.