Transaction für SELECT-Zugriff committen

[Jürgen Malzkorn]

Hallo Herr Kosch,

ich habe RedSys bereits in Ihrem letzten Buch "Interbase Datenbankentwicklung mit Delphi" kennengelernt. Bezüglich eines SELECT-Zugriffs bemerken Sie, daß die Transaction auch dort so kurz wie möglich dauern soll. Nun ist es so, daß unsere Applikation aus der Zeit von Delphi 2 und 3 stammt, also eine BDE-Applikation war. Sie wurde umgestellt in Delphi 5 auf IBX. Die Transaction-Dauer bei Schreibzugriffen ist in der Tat so kurz wie möglich, nämlich nur für die Dauer des Schreibzugriffs. Danach wird die Datenmenge wieder neu geöffnet und auf den zuletzt bearbeiteten Datensatz positioniert. Dasselbe für den SELECT-Zugriff nach dem Muster von RedSys zu organsieren, wäre ein, zeitlich gesehen, nicht vertretbarer Aufwand. Deshalb meine Frage: Hat es wirklich gravierende Nachteile für die Benutzer unserer Software, wenn die Transaction für den Lesezugriff solange dauert, wie das entsprechende Formular oder Grid geöffnet ist? Unmittelbar vor dem Schliessen des jeweiligen Forms, wird ein Commit verschickt, da die Datenmenge nicht mehr angezeigt werden muß.

[Andreas Kosch]

Hallo,

verwendet die Anwendung <b>Snapshot</b> als Einstellung für TIBTransaction? In diesem Fall erhält man immer nur die Sichtweise auf die Daten, die zum Start der eigenen Transaktion vorlag (d.h. die Änderungen anderer Benutzer sind unsichtbar). Über die Eigenschaft <b>IdleTimer</b> sieht IBX einen Weg vor, wie diese Einschränkungen relativ elegant umgangenen werden können, wenn aktuelle Daten notwendig sind

[Jürgen Malzkorn]

Hallo Herr Kosch,

die Transaction-Parameter lauten "read_committed rec_version nowait". Folgende Beschreibung ist noch wichtig: Eine der Entwicklungsvorgaben damals, war die Forderung nach einer MDI-Applikation. Der Anwender muss die Möglichkeit haben, gleichzeitig verschiedene Eingabeformulare (und damit mehrere gleichzeitig offene Datenmengen) zur Bearbeitung aufrufen zu können. Es durfte allerdings nicht so sein, daß durch Betätigung des entsprechenden Navigatorschalters, alle Änderungen/Ergänzungen aller bearbeiteten Datenmengen gleichzeitig gesichert wurden. Es mußte die Möglichkeit geschaffen werden, bspw. bei einer Datenmenge die Änderungen zu übernehmen und bei den anderen, gleichzeitig offenen, zu verwerfen. Daraus resultierte bei der Umstellung von der BDE auf IBX die Vorgehensweise, für jede Datenmenge, die durch den Benutzer gleichzeitig geöffnet werden könnte, eigene TIBTransaction´s einzurichten. Aus diesem Grunde wäre eine Umstellung nach dem Muster von RedSys für lesende Zugriffe sehr aufwendig. Auch ist es wichtig, daß der Transaction-Parameter nicht SNAPSHOT, sondern READ_COMMITTED ist. Der einzelne Benutzer muß unbedingt die bestätigten Änderungen/Ergänzungen anderer Benutzer während seiner Arbeit sehen können

[Andreas Kosch]

Hallo,

es ist ein häufiges Missverständnis, dass nur bei READ COMMTTED die Änderungen anderer Benutzer sichtbar sind. Der SQL Standard sieht vor, dass eine Anwendung mindestens REPEATABLE READ (alias Snapshot beim InterBase) verwenden muss, da nur dann die vom Standard aufgestellen ACID-Anforderungen an eine Transaktion (Atomicity, Consistency, Isolation, Durability) erfüllt werden. Allerdings bedeutet REPEATABLE READ für den InterBase, dass man nur dann die Änderungen anderer Benutzer sieht, wenn man sich selbst eine neue Transaktionsnummer holt und die SELECTs neu ausführen lässt (siehe IdleTimer von IBX).

Für den InterBase bedeutet READ COMMTTED permanenter Stress, da er bei jedem Commit-Aufruf die TIPs (Transaction Iventory Page) aller aktiven Sessions/Transactions neu zusammenstellen muss. Der Server arbeitet nicht so effektiv wie bei REPEATABLE READ, zusätzlich besteht die Gefahr, dass die Anwendung "falsche Daten" sieht. Nur bei REPEATABLE READ kümmert sich die Datenbank automatisch um die Abschottung der Transaktionen, so dass "falsche Daten" sehr unwahrscheinlich sind.

P.S: Erst dann, wenn SERIALISABLE aktiviert wird (steht unter dem InterBase so nicht direkt zur Verfügung), ist eine Datenbank dem SQL-Standard nach vollständig sicher. READ COMMTTED ist nur ein schlechter Kompromiss, bei dem die Datenbank die Verantwortung auf das Programm abwälzt. Als goldener Mittelweg zwischen SERIALISABLE und READ COMMTTED hat sich daher REPEATABLE READ (alias Snapshot beim InterBase) als das übliche Isolationsmodell etabliert

[Jürgen Malzkorn]

Hallo,

ich möchte Ihre Aussagen in keinster Weise anzweifeln, im Gegenteil, ich bin froh, daß ich ein paar Tips zum, aus meiner Sicht, doch heiklen Thema „IBX-Transactions“ bekomme. Gestatten Sie mir aber einige Bemerkungen zu anderen Aussagen, die mir widersprüchlich erscheinen. Die Entwicklerausgaben 4/2001 und 5/2001 beinhalteten jeweils einen Bericht über Interbase-Transaktionen. Dort schreibt der Autor, Karsten Strobel, über den Transaktionsparameter „SNAPSHOT“ (Seite 94 – 4/2001) – Zitat: „Es ist klar, dass die Datenbank einen ziemlich hohen Aufwand betreiben muss, um für Transaktionen im concurrency-Modus dauerhaft die gleiche Sicht auf die Daten aufrecht zu erhalten...“ – Weiter heisst es: „Eine read-committed-Transaktion ist da weniger anspruchsvoll...Man sollte also concurrency-Transaktionen nicht unnötig lange laufen lassen. Meist werden sie ohnehin für automatische, d.h. nicht vom Benutzer gelenkte Aufgaben eingesetzt...“
Nach diesen Sätzen würde man doch vermuten, SNAPSHOT nur dann einzusetzen, wenn man bspw. Reports erstellt (damit die Anwendung keine „falschen Daten“ sieht). Warum haben die Entwickler von IBX die Parameter „read committed“ als Default-Einstellung gewählt? Noch eine Anmerkung zu RedSys. Sie haben mit IdleTime und DefaultAction = TACommit eine elegante Lösung demonstriert, wie man „lesende“ Transaktionen kurz hält. Wenn ich den Quelltext richtig interpretiert habe, funktioniert das aber nur, wenn State = dsBrowse ist. In diesem Fall wird der IdleTimer ausgelöst, ein Commit folgt, die Datenmenge wird mit der richtigen Zeigerposition wieder geöffnet. Der Grund ist klar, sie wollen eine Edit-Aktion durch den Anwender nicht abwürgen. Was ist aber, wenn der Anwender in einem Formular zwei oder drei Felder ändert, und er wird bspw. zu einer Redaktionskonferenz gerufen und vergisst, seine Änderungen zu committen. State steht in diesem Fall auf dsEdit, der IdleTimer wird auf 0 gesetzt und DefaultAction nicht ausgelöst. Die Transaktion läuft im günstigsten Fall dann nur solange, wie die Redaktionskonferenz dauert. Was ich damit sagen will: Ich habe den Eindruck, daß, wenn man eine gute Lösung, wie im Falle von RedSys, gefunden hat, man gleichzeitig auch wieder einen Kompromiss eingehen muss. Wenn dem so ist, stellt sich aber doch gleichzeitig die Frage, ob es überhaupt eine perfekte Transaktionskontrolle gibt

[Andreas Kosch]

Hallo,

es ist in der Tat richtig, dass die meisten SQL-Datenbanken für REPEATABLE READ einen hohen Aufwand (temp. Tabellen) treiben müssen - allerdings mit <b>einer</b> Ausnahme: InterBase. Daher muss man an dieser Stelle aufpassen, wenn man allgemeine Datenbank- bzw. SQL-Bücher liest. Der InterBase hat mit der Multigenerationen-Architektur ein Alleinstellungsmerkmal, dass ihn von allen anderen SQL-Datenbanken unterscheidet. Was bei den anderen SQL-Datenbanken nur mit hohem Aufwand (temp. Tabellen für REPEATABLE READ) geht, erhält man beim InterBase automatisch über die für jede Datensatzversion mitgeführte Transaktionsnummer. Allerdings sorgt die Multigenerationen-Architektur im Gegensatz dazu, dass die für alle anderen SQL-Datenbanken einfachen Aufgaben (READ COMMITTED) für den InterBase etwas komplizierter werden, da nun jede Transaktion ihre Sichtweise (Datensatzversion) erhalten muss.

Im Laufe der Zeit hat IBX seine Standardeinstellungen mehrfach geändert (d.h. Jeff Overcash beugt sich der jeweiligen Mehrheit).

In der Tat haben Sie eine Schwachstelle von RedSys erkannt - es fehlt ein weiterer Timer, der eine Transaktion nach einem festgelegten Timeout (3 Minuten ??) automatisch abwürgt. Allerdings werden Änderungen am Datensatz ja nur in den internen Speicher geschrieben und landen erst beim Post-Aufruf beim InterBase. Daher ist das Problem an dieser Stelle nicht so gravierend, als das man es in jedem Fall nach dem Timeout abwürgen müsste