möglichst kurze Transaktionen

[Hansa]

Hi,

es geht indirekt um dieses Thema:

http://www.delphipraxis.net/internal...9cd23fdac28622

Ich habe das wichtigste rauskopiert, damit nicht jeder alles lesen muß, was hier mit dem Thema nichts zu tun hat:

Zitat:

Zitat von urs.liska

Transaktionen sollten so kurz wie möglich sein. Also nicht beim Öffnen des Fensters starten und beim Schließen beenden. Die Transaktion sollte vor Beginn des zusammenhängenden Vorgangs gestartet und nach Abschluss desselben beendet werden. Sie dient nur dazu, zu garantieren, dass die zusammenhängenden Buchungen nicht nur teilweise durchgeführt werden. Transaktionen sind nicht dazu da, bei Datenbanken so etwas wie ein "Dokument" zu simulieren, das erst am Ende der Sitzung gespeichert wird! Wenn Dir das wichtig ist, solltest Du so etwas wie einen Log-Mechanismus verwenden, der alle Änderungen während der Sitzung speichert, um diese ggfs. rückgängig machen zu können. Im Prinzip geht das auch mit Cached Updates oder ClientDataSets...

Zu viele offene Transaktionen können eine DB natürlich vor allem im Netztwerk schon belasten. Das ist klar, aber es geht mir mehr um den sinnvollen Einsatz derselben. Was er meint ist folgendes, bitte korrigieren, wenn falsch:

Bei einer Rechnung hat man bspw. mehrere Tabellen zu beachten. Rechnungspositionen, Lagerbestand, diverse Statistik-Tables usw., also schon etwas an Aufwand. Jetzt gibt man eine Mengenposition ein und das Programm speichert die ab. Sagen wir mal 10 Tabellen sind davon betroffen. 5 sind fertig und der Server stürzt ab. Dann weiß man ja überhaupt nicht mehr wo man anfangen soll. Am besten rollt man also die ganze Transaktion komplett zurück und fängt neu an.

Jetzt die Hauptfrage:

Dieses Verfahren ließe sich auch hervorragend dazu benutzen, das auf die ganze Rechnung anzuwenden (mit 1 einzigen Transaktion). Also 10 Positionen werden eingegeben, die übliche Kaffeepause, dann weitermachen, aber sobald die Tasse auf dem Tisch steht wieder Absturz. ODER aber: Rechnung wurde komplett eingebenen auf falschen Kunden, kurzerhand Rollback (gesteuert). Das würde dann heißen: übermäßig lange Transaction. Für so was dürfte Urs den "Log-Mechanismus" gemeint haben. Dazu habe ich aber überhaupt keine Idee.

Genauso wenig, was in dem Zusammenhang mit CashedUpdates und ClientDataSet gemeint ist. Wozu soll das gut sein ?

Und dann noch automatische Transaktion. Raff ich auch nicht.

[JoelH]

EIne Transaktion ist dazu da zu garantieren dass in dei DB kommt was zusammen rein muss. Sprich entweder alles oder eben nichts.

Darum sollte man immer relativ wenig Transactieren bzw. die Transaction schnell durchführen !

Warum =>

Weil sonst keiner wirklich parallel auf die Daten zugreifen kann. Denn wenn er auch eine Transaction startet geht sehr wahrscheinlich eien schief. Naja und wenn du dass auch 10000 Transacts. ausweitest (zB. Bank und Buchungen) dann kannste dir vorstellen wieviel da daneben geht udn die Rechner bzw. die DB hängt.

Darum wird angesprochen dass zuerst dein Programm alles Speichert und dann in eienm Rutsch an die DB sendet.

Ein Beispiel:
Ich arbeite gerade an einer Abrechnungsverwaltung. Da geht der User durch etliche Sceens , kann x eingaben machen udn am Ende wird alles gespeichert in der DB.

Ich habe jetzt 2 Lösungsansätze hierzu, einen falschen udn eienn richtigen.

Zuerst der Falsche.
Ich mache eien Transaktion auf und schreibe immer alles was der User verändert ind die DB rein. LEse dort auch alles wieder aus, wenn er den Tab Sheet wechselt usw.
Die Transaction dauet dadurch , zur Not, Stunden.

Andere Möglichkeit, ich lade alle Daten in einen eigeenn Struct-Typ , lasse den User wurschteln was er will und halte alles im Speicher. Erst wenn er senden drückt geeh ich an die DB und versuche sie zu beschreiben. Die Transaktion wird innerhal von sekunden durchgeführt und es ist unwahrscheinlich dass ein anderer User gerade die selben Daten braucht.

[Hansa]

Hi,

:idea: das käme meinem Ansatz entgegen, so was in der Richtung habe ich mir auch schon überlegt, denn ich habe die ganzen DB-Komponenten vorerst außen vor gelassen. Die Eingaben werden in einem schlichten Stringgrid gemacht, da kann ich tun und lassen, was ich will. Also könnte ich doch beides gleichzeitig tun:

1. Die Transaktion kurz halten
2. falsche Eingabe: Stringgrid einfach vergessen. Alles richtig -> speichern und zwar alles auf einen Schlag.

Nur das hier schmeckt mir nicht:

Zitat:

Zitat von JoelH

...und es ist unwahrscheinlich dass ein anderer User gerade die selben Daten braucht.

Bei mir gehts zwar nicht um eine Bank, aber ich glaube kaum, daß eine Bank mit Speicher-Wahrscheinlichkeiten zufrieden wäre. Wenn schon, müßte das alles absolut wasserdicht sein.

[JoelH]

das war ein Beispiel. Dort funktioniert der kram ja.

[Hansa]

Wie was, welcher Kram funktioniert wann :?:

Zitat:

Die Transaktion wird innerhalb von sekunden durchgeführt und es ist unwahrscheinlich dass ein anderer User gerade die selben Daten braucht.

Was ist denn wenn gerade in der Sekunde was passiert ? Bei einer Überweisung von 1.000.000 EUR :?: Da nützt mich eine 99 %ige Wahrscheinlichkeit doch nichts.

[kiar]

hallo hansa

geh mal ins www.entwickler-forum.de und suche mal unter transactionen
dort sind leute die auf diesem gebiet richtig kenne haben.

raik

[JoelH]

@Hansa
Du hast das Prinzip einer Transaktion noch nicht verstanden.
Eine Transaktion sit im Grunde genommen eine gewissen Anzahl von SQL Statements die nacheinander abgespielt werden. Geht nur einer dieser Querys daneben scheitert die gesamte Transaktion und kein Statement wird ausgeführt. Die die ausgeführt wurden werden zurückgenommen. Dadurch erreichst du 100%. Es gibt kein 99%, das ist ja der SInn der Transaktion. Es wird entweder alles ausgeführt oder gar nichts. Und du kannst nach allen Statements immer frei entscheiden => Commit oder ROllback.

[kiar]

noch eine anwort zu clientdataset: hier wird eine instanz in den speicherbereich geladen, und erst wenn der komplett ist wird der datensatz in die db eingelesen.

also es wird immer etwas im speicher gehalten.

[urs.liska]

Hallo Hansa, wie angekündigt lesen wir uns hier wieder.

Was JoelH in seinem ersten Beitrag schreibt, entspricht genau dem, was ich meinte. Ich hoffe, das ist Dir jetzt so weit klar geworden.

Was jetzt die "Konflikte" angeht, kurz gesagt: die 99%ige Wahrscheinlichkeit hast Du, dass es keinen Konflikt gibt, aber du hast 100%ige Sicherheit, dass die DB in jedem Fall konsistent bleibt.

Ich versuche das mal am konkreten Beispiel der Überweisung zu erläutern.
Angenommen Du liest ein, dass Du 2.000 € auf dem Konto und füllst (offline, z.B. in Deiner selbst geschriebenen Datenstruktur) eine Überweisung über 1.500 € aus. In der Zwischenzeit (während Deiner Kaffeepause) führt jemand im Nebenbüro eine Überweisung von 1.000 € durch. Wenn Du vom Kaffee zurück kommst, weißt Du natürlich nicht, dass jetzt nur noch 500 € auf dem Konto sind.
Wenn Du jetzt die Transaktion startest und die Daten einträgst, "sieht" die Transaktion die 500 € und zieht davon 1.500 ab (und spuckt wahrscheinlich eine Fehlermeldung wegen der Kontoüberziehung aus). Hättest Du die Transaktion beim Öffnen des Formulars gestartet, "sähe" die Transaktion den Wert 2.000 € und würde als neuen Kontostand 500 € eintragen, wodurch natürlich die DB fehlerhaft würde.
Damit dies nicht passiert, hat jede DB (individuelle) Methoden, die Datensätze zu sperren. In dem Beispiel hätte der andere Benutzer bei der "langen" Transaktionsversion wahrscheinlich seine Überweisung gar nicht eintragen dürfen, da Du während der Kaffeepause die Tabelle oder die Datensätze gesperrt hast. Oder er bekommt eine Meldung, die besagt, dass er die Transaktion nicht committen kann, bevor Deine Transaktion nicht beendet ist oder so etwas.
Das Thema der Datensatzsperrung und die Frage der "Isolation" der Transaktionen (-->welche Daten aus einer anderen Transaktion "siehst" du) ist aber ziemlich komplex, und ich bin da auch nicht sicher genug, es Dir wirklich zu erklären.

Nochmals: entscheidend ist nicht die 99%ige Wahrscheinlichkeit, keine Interessenskonflikte beim Posten der Daten zu haben, sondern die Garantie der Datenkonsistenz und die Möglichkeit, auf die Konflikte zu reagieren.

Zu der Frage der Automatischen Transaktionen kann ich nichts sagen, da ich keine Ahnung habe, wie FIBPlus damit umgeht.
Bei IBX geht es so (vielleicht hilft das fürs Verständnis): Die IBDatabase-Komponente hat eine Eigenschaft DefaultTransaction, die mit einer IBTransaction-Komponente belegt werden muss. Jede Datenmengenkomponente hat dadurch über die IBDatabase eine Verbindung zu einer Transaktionskomponente.
Wenn man nun nicht mit IBTransaction1.StartTransaction und .Commit oder .Rollback explizit steuert, wann die Transaktionen gestartet und beendet werden, erledigt IBX das von selbst, d.h. ungefähr: jede Aktion wird in einer eigenen Transaktion gekapselt. Die automatische Steuerung ist i.d.R. sehr bequem, man kann aber u.U. unerwartete Ergebnisse bekommen (dafür weiß ich jetzt aber kein Beispiel).
Wenn ich recht weiß, werben FIBPlus und IBO unter Anderem damit, bessere Möglichkeiten der Transaktionssteuerung zu bieten - frag mich aber nicht, welche. Du solltest Dich auf jeden Fall genau damit beschäftigen, denn hier liegen Möglichkeiten für sehr versteckte Fehler und unerklärliche "Datenverluste".
(Da Du in Deinem alten Beispiel aus dem anderen Thread aber mit einer langen expliziten Transaktion arbeitest, sollte das dort nicht der Fehler sein).

Das muss für jetzt genügen. Ich sollte auch noch was anderes tun...

Grüße
Urs

[Hansa]

Ich habe mich jetzt mal etwas schlau gemacht, da ich auf folgendes Problem gestoßen bin. Wie gesagt brauche ich z.B. 10 Update-Tabellen.

Da es sich um Rechnungen handelt, muß ich die trotzdem eingeben können. Sollen die Transaktionen kurz sein, nützt mich das nichts, weil ich an die Artikel ran muß, um überhaupt die Rechnung zu schreiben.

Also soll ich zwei Transaktionen machen: eine lange lesende und eine kurze sachreibende. Ist das so üblich, oder wieder eine Spezialität von FIBplus?