FireDAC Commit Problem

[Eppos]

Hallo zusammen,

ich bin momentan beim umstellen von FibPlus auf FireDAC und jetzt in der Feinabstimmung.
Ich habe mir für die Erleichterung eine kleine ExecSQL Routine geschrieben die für mich inserts und updates übernimmt:

Delphi-Quellcode:

function ExecQuery( Sql : String; Database : TADConnection ) : boolean;
var myQuery : TADQuery;
begin
  myQuery := TADQuery.Create( Application );
  myQuery.Connection := Database;
  myQuery.SQL.Text := Sql;
  myQuery.ExecSQL;
  myQuery.Connection.Commit;  // <-- hier dauert es ca 25 mal so lange wie mit FibPlus
  myQuery.Free;
end;

An der markierten Stelle dauert es ewig.

Hat jemand eine Idee?

Gruß
Eppos

[Daniel]

Es ist TFDQuery, nicht TADQuery, oder?

Schau mal, wie Deine Standard-Einstellungen für FireDAC sind, insbesondere bei den Update- und FetchOptions. Deine Query erbt die Settings der Connection, wenn sie keine eigenen Einstellungen hat.

[Eppos]

TADQuery <-- Arbeite mit Delphi XE2 und (FireDAC) AnyDAC

Ich wollte es eigentlich ohne das Commit machen.
Das Problem daran war aber, dass die Änderungen an den Daten erst nach beenden des Programms geschrieben worden sind und somit erst dann für die anderen Benutzer zugänglich waren - gibt hier eine andere Lösung?

Die Optionen sind natürlich sehr vielseitig, gibt es ganz bestimmte Optionen die man sich anschauen sollte?

[mkinzler]

Erst mal sollte man feststellen, was den genau so lange dauert. Hast Du mal alle anderen Verbindungen zur Datenbank/Connection getrennt?
Der eigentlich Commit sollte schnell gehen.

[haentschman]

Hallo...

:gruebel: heißt das, daß nur mit dem Commit die Daten in der DB ankommen? Steht die Connection auf so etwas wie "AutoCommit"? Wo wird die Transaktion geöffnet welche du mit dem Commit abschließt? Wo ist das Rollback im Fehlerfalle?

[Eppos]

@mkinzler
Ja ich habe alle Verbindungen getrennt, bzw. den Dienst neu gestartet...

@haentschmann
Die Connection steht auf AutoCommit = True
Ein StartTransaction etc. gibt es nicht.

[mkinzler]

Wenn AutoCommit auf True steht, wird je nach Bibliothek entweder die aktuelle Transaktion per Commit abgeschlossen oder ein SavePoint erzeugt. Der explizite Commit beendet dann alle Teiltransaktionen ( Savepoints), bei vielen Statements sind das dann viele.

Schalte mal das Autocommit ab und verwende explizite Transaktionen.

http://docwiki.embarcadero.com/RADSt..._%28FireDAC%29

[Eppos]

@mkinzler
Danke für Info, ich hatte schon Transaktionen eingebaut, jedoch habe ich dann das Problem, dass Datensätze erst nach beenden des Programms in die Datenbank geschrieben werden und somit erst sichtbar für die anderen User sind.
Gibt es hierfür eine Lösung?

[mkinzler]

Die Datnsätze sollten direkt beim Einfügen in der Datenbank landen, nur für andere Verbindungen (wenn nicht dirty read). Durch einen Commit, solten diese für andere Transaktionskontexte sichtbar sein ( andere Clients/andere Datenbankverbindungen).
Ich kenne jetzt AnyDAC/FireDAC nicht im Detail, ist aber bei den Komponenten, die ich kenne alle so.

[Eppos]

Ich hatte/habe bei der Connection bei TxOptions/Isolation/xiReadCommitted hinterlegt...
Und da war das sehr nervige Phänomen

[Uwe Raabe]

Das geht natürlich auch in FireDAC genauso.

Aber warum eigentlich so kompliziert? Die TADConnection/TFDConnection bietet doch direkt eine Methode ExecSQL an - auf Wunsch auch mit Parametern. Damit erübrigt sich doch deine eigene Routine.

[Eppos]

@Uwe Raabe
Ich habe es auch direkt über den ExecSQL in der Connection versucht, nach dem ExecSQL habe ich den Commit aufgerufen gleiches Problem wieder

Welches Isolation sollte man für ein Multiusersystem wählen?

[mkinzler]

Zitat:

Welches Isolation sollte man für ein Multiusersystem wählen?

ReadCommited

[Uwe Raabe]

Zitat:

Zitat von Eppos (Beitrag 1275438)

Ich habe es auch direkt über den ExecSQL in der Connection versucht, nach dem ExecSQL habe ich den Commit aufgerufen gleiches Problem wieder

Der explizite Aufruf von Commit ist schon verdächtig und sollte eigentlich gar nicht nötig sein bzw. ist sogar eher schädlich. Insbesondere da offenbar vorher keine Transaktion begonnen wurde.

[Eppos]

Ich habe Vermutungen...

1. Delphi XE2 Pro. mit AnyDAC hat ein Fehler
2. Delphi XE2 Pro. mit AnyDAC und übers Netzwerk hat ein Problem (Ich glaube gelesen zu haben das das mit der Pro nicht geht)

Weis da jemand was?

[mkinzler]

Die Beschränkung der Pro bezieht sich auf die mitgelieferten dbExpress-Treiber. Mit anderen Fremdomponenten, was AnyDAC ja war ( hat sich mit Integration als FireDAC geänder) tritt diese Beschränkung nicht auf.

[Eppos]

Also mit "commitretaining" geht alles... komisch

[hstreicher]

Commitretaining ist wie ein Schneepflug ,
du schiebst immer mehr Arbeit vor dir her und hast dann irgenwann soviel auf der Schaufel dass nichts mehr vorwärts geht.

Ich empfehle sich mal gründlich in die Verwendung von Transactionen einzulesen/einzuarbeiten.
wenn man das beim Programmdesign am Singleuser Entwickler Arbeitsplatz falsch macht merkt mans nicht
kann man die Produktiven Arbeitsplätze ganz gewaltig ausbremsen

Zu Mkinzlers Antwort dass in einem Multiuser System
Read Commited immer die richtige Auswahl ist , nein das ist falsch
Read Commited ist meist eine gute Wahl,
aber auch die anderen "Isolation Levels" haben Ihre Existenzberechtigung.

[jobo]

Wie sieht es aus, wenn Du das explizite Commit weglässt?
Würde ich jedenfalls empfehlen, ebenso wie ReadCommitted.
Es mag Sonderfälle geben, wo das sinnvoll oder unvermeidbar ist, aber 99%-100% einer Standardanwendung brauchen das nicht.
Wenn es gebraucht wird, sollte man genau wissen, was man tut.

Explizites Commit kannst Du natürlich nicht einfach weglassen, wenn Du im Client auch explizit Transaktionen beginnst. Dann- nur dann- ist ein fehlendes Commit schlecht. An der Stelle würde ich gründlich prüfen, ob die selbst gestarteten Transaktionen notwendig sind und sie im Zweifel entfernen. Prinzip: Keine Transaktionsverwaltung im Client.

[mkinzler]

Interessnat ist, das sein Programm am Anfang, genau das gemacht hat: sich auf das autocommit verlassen.

Den Scheiß mit der expliziten Transaktionssteuerung kam von mir.

Aber ich sehe langsam ein, daß ich keine Ahnung von nix habe und ziehe meinen Vorschlag zurück.

[jobo]

mmh, ich kenne Firedac auch nicht im Detail, halte es aber immer so wie Uwe auch angedeutet hat.
(Ausnahme: In den 2 Fällen wo ich es anders versucht habe, hat es immer Probleme gegeben)

Also, da ich auch keine Praxiserfahrung mit Firedac hab, sag ich es so:
Ich finde explizite Transaktionssteuerung im Client schlecht, so lange bis ich erlebt habe, dass ein Provider das gut umsetzt. Dabei ist mir auch egal, ob die Transaktionssteuerung über die Connection oder über eine separate Kompo läuft.

Vielleicht macht Firedac ja ganz toll und ich hab was neues gelernt.

Für den TE dürfte es sicher unproblematisch sein, die beiden Varianten zu testen.

[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

[MichaelT]

Am besten ist du traced mit dem Monitor mit und schaust dir die Statements an.

Riecht nach 'ähnlich' dem full fetch einer großen Datenmenge nach dem Commit im Falle du benützest eine separate UpdateQuery.

Es ist hilfreich autocommit abzudrehen, da FD autocommit im Falle von FB emuliert in dieser speziellen Situation. Damit kommst aus diesem Eck mal in des Teufels Küche.

Zitat:

Zitat von Eppos (Beitrag 1275422)

TADQuery <-- Arbeite mit Delphi XE2 und (FireDAC) AnyDAC

Ich wollte es eigentlich ohne das Commit machen.
Das Problem daran war aber, dass die Änderungen an den Daten erst nach beenden des Programms geschrieben worden sind und somit erst dann für die anderen Benutzer zugänglich waren - gibt hier eine andere Lösung?

Die Optionen sind natürlich sehr vielseitig, gibt es ganz bestimmte Optionen die man sich anschauen sollte?

[mkinzler]

Zitat:

Es ist hilfreich autocommit abzudrehen, da FD autocommit im Falle von FB emuliert in dieser speziellen Situation.

Was wird da emuliert? Es wird halt ein cimmitReatining ausgeführt, welches eine Commit eines Savepointes ( Teiltranskation) und nicht ein endgültiger (harter) Commit der (Gesamt-)Transaktion ist.

[MichaelT]

Jo eh. Ich beschwer mich eh ned.

Wollte das Verhalten beim lang laufenden Update reproduzieren schaffte es aber nicht im 2.5.3.

Zitat:

Zitat von mkinzler (Beitrag 1275745)

Zitat:

Es ist hilfreich autocommit abzudrehen, da FD autocommit im Falle von FB emuliert in dieser speziellen Situation.

Was wird da emuliert? Es wird halt ein cimmitReatining ausgeführt, welches eine Commit eines Savepointes ( Teiltranskation) und nicht ein endgültiger (harter) Commit der (Gesamt-)Transaktion ist.

[hoika]

Hallo,
ist RequestLive der Query auf True?

Heiko

[Eppos]

@hoika
Ja ist auf requestlive=true. Ist Standard.