FireDAC Commit Problem

[tsteinmaurer]

Aus Entwicklersicht hat AutoCommit den Vorteil, dass man sich um nichts kümmern muss. Transaktionen werden automatisch abgeschlossen, datensensitive Elemente wie zb. DBGrid zeigen auch nach einem TDataSet.Post noch Daten an ohne dass die Datenmenge neu geöffnet werden muss usw. Heisst aber auch, dass wirklich jedes SQL in einer eigenen Transaktion läuft. Bei entsprechender Last und mit dem Multiplikationsfaktor von gleichzeitigen Benutzern kann da über die Zeit schon was zusammenkommen (Transaktions-IDs in Firebird sind 32-bit. Bevor man das erreicht, muss man ein Backup/Restore mit gbak machen).

Aus Firebird-Sicht kann das über die Zeit halt Gift sein, weil die Delphi Client-Bibliotheken hier intern in der Regel ein COMMIT RETAINING machen, was zwar die Änderungen bestätigt, aber den "physischen" Transaktionskontext erhält. Einfach mal die Header-Page der Datenbank mit gstat -h monitoren und schaun, ob die Differenz zwischen Next Transaction und Oldest Active Transaction (OAT) kontinuierlich ansteigt. Ich hab jetzt mittlerweile so viele Kundenumgebungen gesehen, wo genau das passiert und wo dann vom Kunden kommt, dass die DB nach einem Backup/Restore mit gbak schnell ist, aber über die Tage/Wochen kontinuierlich langsamer wird, halt bis zum nächsten gbak-basierten Backup/Restore.

Wo wir wieder bei der Transaktionssteuerung im Client wären. Mit ReadCommitted und Read-Only gibt es eine spezielle/interessante Kombination der Transaktionskonfiguration wo langlaufende Transaktionen oder halt auch ständiges COMMIT RETAINING beim AutoCommit kein echtes langfristiges Performanceproblem darstellen, da hier die OAT trotzdem nachziehen kann.

Und dass andere User/Clients Datenänderungen nicht sehen, kann natürlich auch damit zusammenhängen, dass diese eine RepeatableRead/Snapshot Transaktion verwenden, die nur committete Änderungen sieht zum Zeitupnkt des Transaktionsstarts, unabhängig davon wie oft ich das selbe SQL im Kontext dieser Transaktion ausführe. Man wird immer das selbe Ergebnis erhalten. D.h. hier muss man "hart" committen (COMMIT und nicht COMMIT RETAINING) und eine neue Transaktion starten oder halt ReadCommitted verwenden.

Thomas