Welche Probleme gibt es bei der Verwendung von Transaktionen in einer Datenbank?

Question

Aus dieser Beitrag.Ein offensichtliches Problem ist die Skalierbarkeit/Leistung.Welche anderen Probleme werden durch die Verwendung von Transaktionen verursacht?

Können Sie sagen, dass es zwei Arten von Problemen gibt, eines für Transaktionen mit langer Laufzeit und eines für Transaktionen mit kurzer Laufzeit?Wenn ja, wie würden Sie sie definieren?

BEARBEITEN:Deadlock ist ein weiteres Problem, aber die Dateninkonsistenz kann je nach Anwendungsdomäne schlimmer sein.Geht man von einer transaktionswürdigen Domäne aus (Bankwesen, um das kanonische Beispiel zu verwenden), ist die Möglichkeit eines Deadlocks eher ein Kostenfaktor für die Sicherstellung der Datenkonsistenz als ein Problem bei der Verwendung von Transaktionen, oder würden Sie dem nicht zustimmen?Wenn ja, welche anderen Deadlock-freien Lösungen würden Sie zur Gewährleistung der Datenkonsistenz verwenden?

Answer 1

Dies hängt stark von der Transaktionsimplementierung in Ihrer Datenbank ab und kann auch von der von Ihnen verwendeten Transaktionsisolationsstufe abhängen.Ich gehe hier von „wiederholbarem Lesen“ oder höher aus.Das Offenhalten von Transaktionen über einen längeren Zeitraum (auch solche, bei denen sich nichts geändert hat) zwingt die Datenbank dazu, gelöschte oder aktualisierte Zeilen von sich häufig ändernden Tabellen beizubehalten (nur für den Fall, dass Sie sich entscheiden, sie zu lesen), die andernfalls weggeworfen werden könnten.

Außerdem kann das Zurücksetzen von Transaktionen sehr teuer sein.Ich weiß, dass in der InnoDB-Engine von MySQL das Zurücksetzen einer großen Transaktion VIEL länger dauern kann als das Festschreiben (wir haben gesehen, dass ein Rollback 30 Minuten dauerte).

Ein weiteres Problem betrifft den Datenbankverbindungsstatus.In einer verteilten, fehlertoleranten Anwendung können Sie nie wirklich wissen, in welchem ​​Zustand sich eine Datenbankverbindung befindet.Zustandsbehaftete Datenbankverbindungen können nicht einfach aufrechterhalten werden, da sie jederzeit fehlschlagen können (die Anwendung muss sich merken, was gerade ausgeführt wurde, und sie wiederholen).Statuslose können einfach wieder verbunden werden und der (atomare) Befehl wird erneut ausgegeben, ohne dass der Status (in den meisten Fällen) unterbrochen wird.

Answer 2

Sie können Deadlocks erhalten, auch ohne explizite Transaktionen zu verwenden. Für eine Sache, die meisten relationalen Datenbanken wird eine implizite Transaktion für jede Anweisung, die Sie ausführen gelten.

Deadlocks werden durch den Erwerb mehrerer Schlösser grundsätzlich verursacht werden, und jede Aktivität, die mit einer anderen Aktivität Deadlock kann mehr als eine Sperre beinhaltet das Erfassen, die mindestens zwei gleiche Sperren wie die erste Aktivität beinhaltet erwerben. In einer Datenbank-Transaktion kann einen Teil der erworbenen Sperren länger gehalten werden als sie es sonst gehalten würden - bis zum Ende der Transaktion, in der Tat. Die längeren Sperren gehalten werden, die Chance auf eine Sackgasse größer. Aus diesem Grund ist eine längere andauernde Transaktion eine größere Chance auf Deadlock als ein kurzes hat.

Answer 3

Ein Problem bei Transaktionen ist, dass es möglich ist (unwahrscheinlich, aber möglich) Deadlocks in der DB zu bekommen. Sie müssen verstehen, wie Ihre Datenbank funktioniert, Schlösser, tätigt, etc, um diese interessanten / frustrierend Probleme zu debuggen.

-Adam

Answer 4

Ich denke, das Hauptproblem bei der Design-Ebene ist. Auf welcher Ebene oder Ebenen innerhalb meiner Anwendung kann ich Transaktionen nutzen.

Zum Beispiel könnte ich:

• Erstellen Transaktionen innerhalb von gespeicherten Prozeduren,
• Verwenden Sie den Datenzugriff API (ADO.NET) Transaktionen steuern
• Verwenden Sie irgendeine Form von impliziten Rollback höher in der Anwendung
• Eine verteilte Transaktion in (über DTC / COM +).

Mit mehr als eine dieser Ebenen in der gleichen Anwendung scheint oft die Leistung und / oder Datenintegritätsprobleme zu schaffen.