Transaktionen und Connections

[charlytango]

Hi,

in einem Anwendungsprogramm möchte ich Zb ein Formular mit einem "Abbrechen" Button ausstatten. In diesem Formular sind eine Anzahl von Änderungsmöglichkeiten angeboten deren Änderungen ich transaktionssichern möchte.

Also: Zuerst das Formular nur anzeigen -- Druck auf einen "Edit" Button -- Transaktion starten -- Änderungen erlauben -- User drückt entweder aus Speichern, dann Wird die Transaktion committed oder beim Abbrechen Button wird ein Rollback gemacht.
Meinetwegen auch mit Cachedupdates.

Nun arbeitet jemand am Formular_A, ist mitten in der Arbeit und jemand ruft an. Er braucht ein Formular_B das er aufrufen kann ohne Formular_A zu schließen.

Soweit ist das kein Problem, aber:
Braucht jede Transaktion (SQLDB oder ZEOS) eine eigene Connection zur DB oder können mehrere Transaktionen über ein einzelnes ConnectionObjekt laufen ?

Dementsprechend würde jedes Formular seine eigene TSQLtransaction brauchen.

Nachdem da so einige Formulare Frames auf mich zukommen würde ich das in einen Vorfahren einbauen wollen.

Das hat natürlich auch Auswirkungen auf den DB-Server der bei Mehrbenutzerbetrieb der Anwendung auch gleich um ein vielfaches mehr Connections bereitstellen muß.

THX

[af0815]

Transaktionen sind so kurz wie möglich zu halten, lernt man in jeden MS DB Kurs.

Der Server muss für jede Transaktion Ressourcen halten, noch dazu wird normalerweise die DB mit einem Lock versehen, der je nach Transaktionisolationsmodus bis hin zur Sperre von Tabellen bzw. Teilbereichen führt. Das in Folge zu deadlocks mit anderen Transaktionen führen. Bei den Administrationskursen zum MSSQL ist dieses und andere Design Themen schon etwas wo man sich beschäftigen muss.

Wenn ich bei einer App draufkomme, das der Programmiere den User über die Laufzeit der Transaktion bestimmen lässt, ist die App gesperrt. Sowas kann dir als Admin am Server nur Ärger bereiten.

[icho2099]

Transaktionen sind so kurz wie möglich zu halten, lernt man in jeden MS DB Kurs.

Deshalb habe ich für jede Entität ein Objekt mit allen Datenfeldern. Das Objekt wird aus der/den Tabellen der DB kreiert und dann an die Form zum Show/Edit übergeben.
Die Form selber kennt keine DB. Änderungen werden an den Datenfeldern der Objekte vorgenommen.
Die Objekte werden in einer Factory erzeugt.
Das Speichern in der DB übernehmen die Objekte selber.

[charlytango]

In euren Antworten ist schon einiges drin worauf zu achten ist und was hält noch tiefer geht.
So eine Factory ist nicht Mal eben so zusammengeklickt.

Meine Frage ob eine Transaktion eine eigene Connection braucht ist noch offen.

[Frickler]

Meine Frage ob eine Transaktion eine eigene Connection braucht ist noch offen.

Kommt auf die Datenbank an. Bei Firebird kann eine Connection mehrere Transaktionen haben, aber das ist eine echte Ausnahme. Alle anderen (man möge mich korrigieren) benötigen eine Connection pro Transaktion.

[gladio]

Im Allgemeinen reicht eine Connection zwischen Anwendung und DB aus.
Öffnen der Connection bei Programmstart, bzw. wenn sie gebraucht wird, Schließen bei Programmende, bzw. wenn nicht mehr gebaucht wird.
Alle Transaktionen laufen dann über diese Connection.
Mehrere Connections sind möglich, Geschmackssache. Wird dann irgendwann unübersichtlich.
Notwendig bei mehreren Datenbanken (nicht Tabellen) in der Anwendung.

[charlytango]

hmm... das sind jetzt mal schon zwei gegensätzliche Antworten --- hmmmm

[gladio]

ähm, meine Weisheiten beziehen sich auf Erfahrungen zu Einzelplatzanwendungen.

[charlytango]

Es geht definitiv um eine Multiuseranwendung im Netzwerk.
Mehrere Benutzer bearbeiten gleichzeitig unterschiedliche (oder eben fallweise die gleichen) Geschäftsprozesse ohne dass sie voneinander wissen.
Ebenso kann es zu unterschiedlichen Laufzeiten kommen (Stichwort Remote oder Home Office).

Genau das muss die Applikation in Zusammenarbeit mit der Datenbank managen.

Es geht in diesem speziellen Fall nicht darum welche Strategien eingesetzt werden sollen -- das ist längst geklärt und erprobt.
Es geht darum ob man zur Umsetzung in Lazarus (wohl eher mit ZEOS als mit SQLDB) für die gleichzeitige Bearbeitung unterschiedlicher Bereiche Pro DB-Connection mehrere Transaktionen pro DB-Connection braucht oder ob man mehrere DB-Verbindungen nutzen muss die jede ihre eigene Transaktion hat.

Das wirkt sich auch auf den Speicherbedarf am SQL-Server aus.

[af0815]

Das wirkt sich auch auf den Speicherbedarf am SQL-Server aus.

<ich würde sagen Transaktion und den Transaktion Isolations Level muss man dabei betrachten. Soweit mir bekannt ist, haben alle professionale System ähnliche Ansätze

Allgemein:
https://de.wikipedia.org/wiki/Isolation_(Datenbank)
Spezieller:
https://learn.microsoft.com/en-us/sql/o ... rver-ver16
https://www.postgresql.org/docs/current ... n-iso.html

Ich kann da nur über MS-SQL spezieller reden,
Als Faustregel eine Connection per Server, besser per DB, weil man damit man dem Server wieder interne Routingarbeit abnimmt. Vor allen, weil Sperren, Transaktionen und Precompilate IMHO per DB gehalten werden. Gerade im Multiuser Bereich ist die Transaktion so kurz wie möglich zu halten um deadlocks zu vermeiden.

Zeos hat meiner Erfahrung nach, noch mehr Feintuning Möglichkeiten als SQLDB. ABer es ist nicht immer 100% in sync mit dem aktuellesten Lazarus. Wenn man nur stabile Versionen von Lazraus verwendet gibt es keine Probleme.