- \n
- BeginTrans<\/b>: Startet eine Transaktion, um mehrere Operationen als Einheit auszuführen.<\/li>\n
- CommitTrans<\/b>: Bestätigt eine laufende Transaktion und speichert die Änderungen dauerhaft in der Datenbank.<\/li>\n
- RollbackTrans<\/b>: Bricht eine Transaktion ab und stellt die Daten vor der Transaktion wieder her.<\/li>\n<\/ul>\n
Beispiel für eine Transaktion<\/h2>\n
In einem einfachen Beispiel haben wir eine Tabelle namens tblKonten<\/b> angelegt, die wir wie in Bild 1 im SQL Server entworfen haben.<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2024_06\/pic_450_001.png\")
<\/p>\nBild 1: Die Tabelle tblKonten im SQL Server<\/span><\/b><\/p>\n
Hier finden wir die Felder KontoID <\/b>(Primärschlüsselfeld der Tabelle), Kontostand <\/b>(Datentyp money<\/b>, speichert den aktuellen Kontostand und darf in diesem Fall nicht kleiner als 0 <\/b>werden) und Bezeichnung <\/b>(nvarchar(255)<\/b>, speichert eine Bezeichnung für das Konto).<\/p>\n
Die Tabelle kannst Du mit der folgenden T-SQL-Anweisung in einer SQL Server-Datenbank anlegen:<\/p>\n
CREATE TABLE dbo.tblKonten ( KontoID INT IDENTITY(1,1) PRIMARY KEY, Kontostand MONEY NOT NULL DEFAULT 0 CHECK (Kontostand >= 0), Bezeichnung NVARCHAR(255) NULL);<\/pre>\n
Der besseren Übersichtlichkeit halber haben wir der Beispieldatenbank eine Tabellenverknüpfung auf diese Tabelle hinzufügt. Die Transaktion wollen wir jedoch nicht auf Basis der Tabellenverknüpfungen durchführen (was auch möglich wäre), sondern auf Basis der SQL Server-Tabellen über eine entsprechende Connection<\/b>.<\/p>\n
Dazu starten wir in der Prozedur aus Listing 1 mit dem Deklarieren eines Connection<\/b>-Objekts namens cnn<\/b>. Danach öffnen wir die Verbindung mit der Open<\/b>-Methode.<\/p>\n
Public Sub <\/span>TransaktionBank()\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n Set<\/span> cnn = New<\/span> ADODB.Connection\r\n cnn.ConnectionString = \"Provider=MSOLEDBSQL;Data Source=amvDesktop2023;\" _\r\n & \"Initial Catalog=Transaktionen;Integrated Security=SSPI;\"\r\n cnn.Open\r\n \r\n cnn.BeginTrans\r\n \r\n On Error GoTo<\/span> Fehler\r\n \r\n ''1 Geld von Konto A abbuchen\r\n cnn.Execute \"UPDATE tblKonten SET Kontostand = Kontostand - 100 WHERE KontoID = 1\"\r\n \r\n ''2 Geld auf Konto B gutschreiben\r\n cnn.Execute \"UPDATE tblKonten SET Kontostand = Kontostand + 100 WHERE KontoID = 2\"\r\n On Error GoTo<\/span> 0\r\n \r\n cnn.CommitTrans\r\n MsgBox<\/span> \"Überweisung erfolgreich!\", vbInformation\r\n Exit Sub<\/span>\r\n \r\nFehler:\r\n cnn.RollbackTrans\r\n MsgBox<\/span> \"Fehler aufgetreten - Überweisung wurde storniert!\", vbCr<\/span>itical\r\nEnd Sub<\/span><\/pre>\nListing 1: Diese Prozedur führt eine einfache Transaktion durch.<\/span><\/b><\/p>\n
Anschließend starten wir bereits die Transaktion mit der Methode BeginTrans <\/b>des Connection<\/b>-Objekts. Diese Methode hat keine Parameter. Die einzige Eigenschaft, die sie hat, ist das Objekt, in dessen Kontext sie aufgerufen wird – sie bezieht sich nun auf die Verbindung aus cnn<\/b>.<\/p>\n
Danach wollen wir eine Banktransaktion ausführen, die sich vereinfacht aus dem Abbuchen eines bestimmten Betrags von einem Konto und dem Hinzubuchen des gleichen Betrags zu einem anderen Konto zusammensetzt.<\/p>\n
Dazu sind zwei UPDATE<\/b>-Anweisung nötig, mit denen wir die betroffenen Datensätze anpassen.<\/p>\n
Dass dabei etwas nicht funktioniert, wollen wir am Auftreten eines Fehlers festmachen.<\/p>\n
Dazu deaktivieren wir die eingebaute Fehlerbehandlung und sorgen mit On Error Resume Fehler<\/b> dafür, dass der Code bei einem Fehler an der Sprungmarke Fehler <\/b>weiterläuft.<\/p>\n
Anschließend führen wir die erste der beiden UPDATE<\/b>-Anweisungen durch, mit der wir den Kontostand des Kontos mit dem Wert 1 <\/b>im Feld KontoID <\/b>um 100 <\/b>verringern.<\/p>\n
Die zweite UPDATE<\/b>-Anweisung erhöht den Wert des zweiten Kontos um 100.<\/p>\n
Da hier bereits ein entsprechender Fehler aufgetreten sein sollte, können wir die eingebaute Fehlerbehandlung mit On Error Goto 0 <\/b>wieder aktivieren.<\/p>\n
Schließlich führen wir mit der CommitTrans<\/b>-Methode des Connection<\/b>-Objekts die Transaktion endgültig durch und liefern eine entsprechende Erfolgsmeldung.<\/p>\n
Es kann jedoch auch ein Fehler aufgetreten sein. Zu Beispielzwecken haben wir dazu bei der Tabellendefinition angegeben, dass der Wert des Feldes Kontostand <\/b>niemals kleiner als 0 <\/b>werden darf.<\/p>\n
Wenn wir also eine Überweisung durchführen, die mit der ersten UPDATE<\/b>-Anweisung dafür sorgt, dass der Kontostand auf dem ersten Konto kleiner wird als 0<\/b>, löst dies einen Fehler aus und wir landen bei der Sprungmarke Fehler<\/b>.<\/p>\n
Hier wird die Transaktion mit der Methode RollbackTrans <\/b>komplett rückabgewickelt und es erscheint eine entsprechende Meldung (siehe Bild 2).<\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2024_06\/pic_450_002.png\")
<\/p>\nBild 2: Die Tabelle tblKonten nach einem Fehler innerhalb der Transaktion<\/span><\/b><\/p>\n
Das ACID-Prinzip<\/h2>\n
Transaktionen sollen das Einhalten des ACID<\/b>-Prinzips sicherstellen. Dieses besteht aus:<\/p>\n
- \n
- Atomicity <\/b>(Atomarität): Entweder alle Änderungen oder keine – keine halben Updates.<\/li>\n
- Consistency <\/b>(Konsistenz): Datenbank bleibt immer in einem gültigen Zustand.<\/li>\n
- Isolation <\/b>(Isolation): Eine Transaktion sieht keine halbfertigen Änderungen anderer.<\/li>\n
- Durability <\/b>(Dauerhaftigkeit): Nach CommitTrans<\/b> sind Änderungen dauerhaft gespeichert.<\/li>\n<\/ul>\n
Was genau geschieht bei der Transaktion, wenn diese fehlschlägt?<\/p>\n
- \n
- Die Transaktion wird gestartet.<\/li>\n
- Die erste UPDATE<\/b>-Anweisung wird ausgeführt und der Betrag wird vom ersten Konto abgezogen.<\/li>\n
- Die Änderung wird nur im Speicher (Buffer Pool) und in der Transaction Log-Datei (LDF) gespeichert – aber noch nicht endgültig in die Datenbank (MDF) geschrieben.<\/li>\n
- Die zweite UPDATE<\/b>-Anweisung schlägt fehl (zum Beispiel, weil das Konto nicht existiert).<\/li>\n
- Die Prozedur erkennt den Fehler und führt die RollbackTrans<\/b>-Methode aus.<\/li>\n
- Alle Änderungen seit BeginTrans <\/b>werden verworfen, und der vorherige Zustand wird aus dem Transaktionsprotokoll (Transaction Log) wiederhergestellt.<\/li>\n<\/ul>\n
Kann ich den aktuellen Zustand während einer Transaktion prüfen?<\/h2>\n
Wir können den aktuellen Zustand prüfen, aber bei den Standardeinstellungen nur innerhalb der Transaktion – das ist sowohl bezüglich des Zeitraums als auch bezüglich der Verbindung zu sehen.<\/p>\n
Wir können also zum Beispiel zwischen die erste und die zweite UPDATE<\/b>-Anweisung die folgenden Anweisungen einfügen, um die zu diesem Zeitpunkt gültigen Kontostände zu betrachten (das Beispiel enthält nur die beiden Konten, daher müssen wir hier nicht filtern):<\/p>\n
Dim <\/span>rst As <\/span>ADODB.Recordset\r\nSet<\/span> rst = cnn.Execute(\"SELECT * FROM tblKonten\")\r\nDo While<\/span> Not<\/span> rst.EOF\r\n Debug.Print<\/span> rst!KontoID, rst!Kontostand\r\n rst.MoveNext<\/span>\r\nLoop<\/span><\/pre>\nHier sehen wir den bereits reduzierten Kontostand des ersten Kontos und den noch nicht erhöhten Kontostand des zweiten Kontos.<\/p>\n
Das war der zeitliche Aspekt. Wir können den Kontostand nicht von außerhalb der Verbindung betrachten. Wir können also nicht zum Beispiel die Tabellenverknüpfung auf diese Tabelle in Access öffnen. Der Grund ist, dass die Tabelle beziehungsweise die betroffenen Datensätze zu diesem Zeitpunkt durch die Transaktion gesperrt sind.<\/p>\n
Das ist wichtig, damit nicht ein anderer Prozess in der Zwischenzeit auf diese Datensätze zugreift und sie ändert.<\/p>\n
Wir können aber ungeachtet von Einstellungen mit dem folgenden Befehl vom SQL Server Management Studio aus auf die aktuellen Daten der Tabelle zugreifen:<\/p>\n
SELECT * FROM tblKonten WITH (NOLOCK);<\/pre>\n
Dies liefert im aktuellen Beispiel den bereits reduzierten Wert im Feld Kontostand <\/b>des ersten Datensatzes und den noch nicht geänderten Wert des zweiten Kontos.<\/p>\n
Das Verhalten während der Durchführung von Transaktionen können wir in einem bestimmten Rahmen steuern.<\/p>\n
Dazu hält die Connection<\/b>-Klasse für uns die Eigenschaft IsolationLevel <\/b>vor.<\/p>\n
IsolationLevel in ADODB: Transaktionssicherheit und Parallelität<\/h2>\n
Die IsolationLevel<\/b>-Eigenschaft in ADODB.Connection <\/b>bestimmt, wie eine Transaktion mit konkurrierenden Datenbankzugriffen umgeht.<\/p>\n
Sie legt fest, welche Änderungen von anderen Transaktionen sichtbar sind und schützt so vor Inkonsistenzen wie Dirty Reads<\/b>, Non-Repeatable Reads <\/b>und Phantom Reads<\/b> (wir erläutern diese Begriffe nachfolgend). Je nach gewähltem Wert für die Eigenschaft IsolationLevel <\/b>steigt die Datensicherheit, jedoch oft auf Kosten der Parallelität.<\/p>\n
- \n
- Bei adXactReadUncommitted <\/b>(IsolationLevel = 1<\/b>) können Dirty Reads auftreten, was bedeutet, dass eine Transaktion Änderungen sehen kann, die von einer anderen Transaktion noch nicht bestätigt wurden. Falls diese zweite Transaktion später zurückgesetzt wird (RollbackTrans<\/b>), könnten die gelesenen Daten falsch oder inkonsistent sein. Dieses Level ist zwar performant, aber risikobehaftet.<\/li>\n
- Ein sicherer Standard ist adXactReadCommitted <\/b>(IsolationLevel = 2<\/b>). Hier werden Dirty Reads verhindert, da nur bereits commitete Daten von anderen Transaktionen gelesen werden können. Allerdings sind Non-Repeatable Reads möglich, bei denen sich Daten während einer Transaktion ändern können, wenn eine andere Transaktion sie modifiziert und bestätigt.<\/li>\n
- Mit adXactRepeatableRead <\/b>(IsolationLevel = 3<\/b>) wird zusätzlich sichergestellt, dass Daten während einer Transaktion nicht geändert oder gelöscht werden, was Non-Repeatable Reads verhindert. Allerdings können weiterhin Phantom Reads auftreten – das bedeutet, dass sich die Ergebnismenge einer Abfrage verändert, wenn eine andere Transaktion neue Zeilen hinzufügt.<\/li>\n
- Das höchste Sicherheitsniveau bietet adXactSerializable <\/b>(IsolationLevel = 4<\/b>). Hier werden Dirty Reads, Non-Repeatable Reads und Phantom Reads vollständig ausgeschlossen, indem andere Transaktionen während der Laufzeit gesperrt werden. Dies sorgt für maximale Datenintegrität, kann aber zu langen Sperrzeiten und reduzierter Parallelität führen.<\/li>\n
- Eine moderne Alternative stellt adXactSnapshot <\/b>(IsolationLevel = 4096<\/b>) dar, die in SQL Server über Row Versioning arbeitet. Anstatt Sperren zu setzen, erhält jede Transaktion eine eigene konsistente Sicht auf die Daten, ohne andere Transaktionen zu blockieren. Das verhindert Sperrkonflikte und bietet eine gute Balance zwischen Konsistenz und Performance.<\/li>\n<\/ul>\n
Die Wahl des richtigen Wertes für die Eigenschaft IsolationLevel <\/b>hängt von den Anforderungen der Anwendung ab: Höhere Isolation bietet mehr Datensicherheit, kann aber die Performance beeinträchtigen. In Szenarien mit vielen parallelen Zugriffen ist daher ein durchdachtes Transaktionsmanagement entscheidend.<\/p>\n
Die Eigenschaft IsolationLevel <\/b>stellen wir für das Connection<\/b>-Objekt ein. <\/p>\n
Deadlocks durch Transaktionen<\/h2>\n
Ein Deadlock tritt in SQL Server auf, wenn zwei oder mehr Transaktionen sich gegenseitig blockieren und keiner der Prozesse fortfahren kann, weil jeder auf eine Ressource wartet, die von einem anderen Prozess gesperrt wurde.<\/p>\n
Dadurch entsteht eine zyklische Blockade, die nur durch einen Eingriff von SQL Server oder den Abbruch einer der Transaktionen aufgelöst werden kann. <\/p>\n
Beispiel für einen Deadlock<\/h2>\n
Wenn wir die oben angegebene Operation, bei der wir zuerst den Datensatz mit der ID 1 ändern und dann den mit derr ID 2, in einer parallel stattfindenden Transaktion andersherum ausführen, kann es zu einem Deadlock kommen.<\/p>\n
Dazu müssten wir zwei Access-Instanzen öffnen, von denen eine die Beispielprozedur Deadlock1 <\/b>schrittweise ausführt und eine die Beispielprozedur Deadlock2<\/b>. Wir öffnen also zwei Mal Access und darin jeweils die gleiche Datenbank.<\/p>\n
Deadlock1 enthält innerhalb der Transaktion die folgenden beiden Anweisungen:<\/p>\n
cnn.Execute \"UPDATE tblKonten SET Guthaben = Guthaben - 100 WHERE KontoID = 1\"\r\ncnn.Execute \"UPDATE tblKonten SET Guthaben = Guthaben + 100 WHERE KontoID = 2\"<\/pre>\n
In der Prozedur Deadlock2<\/b>, die wir in der zweiten Session ausführen, finden wir die Anweisungen in dieser Reihenfolge:<\/p>\n
cnn.Execute \"UPDATE tblKonten SET Guthaben = Guthaben + 100 WHERE KontoID = 2\"\r\ncnn.Execute \"UPDATE tblKonten SET Guthaben = Guthaben - 100 WHERE KontoID = 1\"<\/pre>\n
Nun führen wir schrittweise die Prozedur Deadlock1 <\/b>in der ersten Session aus bis zur Anweisung, die Konto 1 ändert.<\/p>\n
Dann führen wir in der zweiten Session schrittweise die Prozedur Deadlock2 <\/b>aus und bleiben bei der Anweisung hängen, die Konto 1 ändern will.<\/p>\n
Wir können nun noch in Deadlock1 <\/b>in der ersten Session fortfahren, bleiben dort aber auch hängen.<\/p>\n
Der Deadlock entsteht hier, weil die beiden Sessions sich gegenseitig blockieren.<\/p>\n
Schließlich bricht Session 2 mit einem Fehler aus der Blockade aus, weil ein Timeout auftritt.<\/p>\n
Dies geschieht normalerweise nach 30 Sekunden. Wir können diesen Zeitraum aber durch Einstellen der Eigenschaft ConnectionTimeout <\/b>des Connection<\/b>-Objekts auf einen anderen Wert wie beispielsweise 10 <\/b>ändern.<\/p>\n
Einen solchen Deadlock können wir übrigens verhindern, indem wir ausschließen, dass Änderungsanweisungen wie hier in unterschiedlicher Reihenfolge auf die beiden gleichen Datensätze auswirken.<\/p>\n
Vermeintlicher Deadlock bei identischer Reihenfolge<\/h2>\n
Wenn wir in beiden Sessions die Prozedur Deadlock1 <\/b>aufrufen und schrittweise durchlaufen und bei der ersten Session nach der Aktualisierung des Datensatzes mit dem Primärschlüsselwert 1 <\/b>stehenbleiben und das gleiche in der zweiten Session erledigen, bleibt die Verarbeitung ebenfalls stehen.<\/p>\n
Dabei handelt es sich nun aber nicht um einen Deadlock, sondern um eine Datensatzsperre, die verhindert, dass auch die zweite Session auf den Datensatz mit dem Primärschlüsselwert 1 <\/b>zugreift.<\/p>\n
Wo ist der Unterschied? Es gibt keine Blockade. Die zweite Session wird nur solange blockiert, bis die erste Session den Datensatz mit dem Primärschlüsselwert 1 nicht mehr sperrt, was in der Regel schnell geschieht.<\/p>\n
Zusammenfassung und Ausblick<\/h2>\n
Das Konzept der Transaktionen ist wichtig für Vorgänge, die nur durchgeführt werden sollen, wenn jeder einzelne Teilschritt abgeschlossen ist.<\/p>\n
Deshalb bietet ADODB mit den drei Anweisungen BeginTrans<\/b>, CommitTrans <\/b>und RollbackTrans <\/b>die Möglichkeit, mehrere Anweisungen zu einer Transaktion zusammenzufassen, wobei wir vor dem Aufruf von CommitTrans <\/b>oder RollbackTrans <\/b>prüfen können, ob alle Anweisungen erfolgreich waren.<\/p>\n","protected":false},"excerpt":{"rendered":"
Transaktionen im Kontext von Datenbankanwendungen sind mehrere SQL-Anweisungen zum Ändern, Löschen oder Hinzufügen von Daten, die entweder alle oder gar nicht ausgeführt werden. Wir markieren den Start einer solchen Transaktion durch eine bestimmte Methode, führen dann eine oder mehrere SQL-Anweisungen aus und entscheiden dann, ob die Transaktion abgebrochen oder abgeschlossen werden soll. Wenn die Transaktion abgebrochen wird, werden alle seit Beginn der Transaktion in ihrem Kontext durchgeführten Änderungen rückgängig gemacht. In diesem Artikel sehen wir uns an, wie wir solche Transaktionen mit der Execute-Methode von ADODB umsetzen können.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662024,66062024,44000008,44000020],"tags":[],"yst_prominent_words":[],"class_list":["post-55000450","post","type-post","status-publish","format-standard","hentry","category-662024","category-66062024","category-Datenzugriffstechnik","category-Entity_Framework_Core"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000450","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/comments?post=55000450"}],"version-history":[{"count":0,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000450\/revisions"}],"wp:attachment":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/media?parent=55000450"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/categories?post=55000450"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/tags?post=55000450"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/yst_prominent_words?post=55000450"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Ein sicherer Standard ist adXactReadCommitted <\/b>(IsolationLevel = 2<\/b>). Hier werden Dirty Reads verhindert, da nur bereits commitete Daten von anderen Transaktionen gelesen werden können. Allerdings sind Non-Repeatable Reads möglich, bei denen sich Daten während einer Transaktion ändern können, wenn eine andere Transaktion sie modifiziert und bestätigt.<\/li>\n
- Consistency <\/b>(Konsistenz): Datenbank bleibt immer in einem gültigen Zustand.<\/li>\n
- CommitTrans<\/b>: Bestätigt eine laufende Transaktion und speichert die Änderungen dauerhaft in der Datenbank.<\/li>\n