Lade...
 

Transaktionen (Abbruch)

Beispiele zur Rücknahme bestimmter Systemzustände beim Abbruch einer Datenbank-Transaktion

In den folgenden Beispielen steht AbortTXN sowohl für die InstantView®-Anweisung AbortTXN, für den Abbruch der Verarbeitung mittels der Anweisung cancel oder aufgrund eines aufgetretenen Fehlers.

Var(x, coll)

1 -> x
CreatePersObject(CX_ITEM)    // Txn startet hier
-> x
. . .
AbortTXN

Das persistente Objekt CX_ITEM existiert nicht mehr (dafür sorgt ObjectStore), und es wäre fatal, wenn x auf dieses Objekt verweisen würde. Die Variable x wird deshalb vom ClassiX®-System auf den Wert 1 zurückgesetzt.

1 -> x
"uniqueID = \"E0025\"" FindFirst(CX_ITEM)    // Txn startet hier
-> x
.  .  .
AbortTXN

Das gefundene Objekt existiert natürlich weiterhin, aber auch hier wird x auf den Wert 1 zurückgesetzt.

CreatePersCollection -> coll
EndTXN                            // dies geschieht in einer anderen Transaktion
.  .  .
CreatePersObject(CX_ITEM)         // die uns interessierende Txn startet hier
coll Insert
AbortTXN

Das gerade erzeugte Objekt gibt es nicht mehr, und die persistente Collection enthält auch keinen Verweis auf dieses Objekt. Die Rücknahme dieser Aktionen geschieht ausschließlich durch das Rollback der ObjectStore-Datenbank.

CreateTransCollection -> coll
.  .  .
CreatePersObject(CX_ITEM)         // Txn startet hier
coll Insert
AbortTXN

Der Transaktionsmechanismus von ObjectStore bezieht sich nur auf persistente Daten. Die transiente Collection würde weiter auf das nicht mehr existierende Objekt verweisen. Das wäre ein Widerspruch zum Verhalten persistenter Collections und auch grob falsch! Deshalb setzt das ClassiX®-System alle die transienten Collections, die innerhalb der gerade abgebrochenen Transaktion verändert wurden, auf den Zustand zu Beginn der Transaktion zurück.

CreateTransObject(CX_UNIT_PARAMETER) -> x
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
x Put
AbortTXN

Das transiente Objekt wird durch den Abbruch der Transaktion nicht verändert!

Im Gegensatz zu transienten Collections sind die Veränderungen transienter Objekt nicht transaktionsbezogen.

Obwohl eine Rücknahme der Änderungen transienter Objekte bei Transaktionsabbruch durchaus wünschenswert wäre, wurde dies wegen des hohen Aufwandes im ClassiX®-System nicht implementiert.
Man kann Beispiele mit transienten Objekte so umschreiben, dass eine Variable nur bei erfolgreichem Ende der Transaktion auf das transiente Objekt verweist:

NULL -> x
.  .  .
0 FindAll(CX_UNIT_PARAMETER)         // Txn startet hier
CreateTransObject(CX_UNIT_PARAMETER) -> x
x Put
AbortTXN

Wegen der fehlgeschlagenen Transaktion hält Variable x nicht das transiente CX_UNIT_PARAMETER-Objekt, und dieses "umsonst" erzeugte Objekt wird demnächst automatisch von der Garbage-Collection entfernt.

[ 1 ] -> x // ein Vektor "zweites Element" x Insert . . . 0 FindAll(CX_UNIT_PARAMETER) // Txn startet hier x Insert // ein weiteres Element AbortTXN

Nach Abbruch der Transaktion besteht der Vektor wieder nur aus den beiden ersten Element.

Soweit besteht Analogie zu transienten Collections.

[ 1 ] -> x // ein Vektor "zweites Element" x Insert 0 FindAll(CX_UNIT_PARAMETER) x Insert EndTXN . . . 0 FindAll(CX_UNIT_PARAMETER) // Txn startet hier x Remove AbortTXN

Nach Remove wird der Vektor nicht zurückgesetzt. Das ist konzeptionell falsch.
Dieser Fehler wird in einer der nächsten ClassiX®-Versionen beseitigt!