Transaktionen mit IBX

[Klaus Kirchhoff]

Hallo,
kann mir mal jemand den Unterschied zwischen CommitRetaining ond Commit
bzw RollbackRetaining und Rollback und wann man welche Variate nutz?

Vielen Dank

[Gesine Kuhlmann]

Hi Klaus,

Bei den ...Retaining-Methoden wird nach Beendigung der laufenden Transaktion sofort eine neue gestartet, welche den aktuellen Transaktionskontext beibehält. Somit steht die zuvor bearbeitete Datenmenge ohne weiteres Zutun wieder zur Verfügung ( Besonders praktisch z.B. in DBGrids ). Leider hat ein solcher Automatismus natürlich auch Nebenwirkungen z.B. bei 'schlecht' gewählten Select-Statements und serverintern auf die OIT/OAT Verwaltung. So kann man schwerlich festlegen, wann welche Methode die günstigste ist.

Gruss
Gesin

[Andreas Kosch]

Hallo,

als Ergänzung zur Antwort von Gesine kann ich nur eines beifügen: Wenn man der Bequemlichkeit wegen auf CommitRetaining zurückgreift, sollte man trotzdem so häufig wie möglich (zum Beispiel beim Schließen des Formulars etc.) ein "richtiges" Commit hinterherschicken. Oder anders gesagt: CommitRetaining nur dann einsetzen, wenn man einen Vorteil davon hat

[Günter Forster]

Hallo,

ich nutze ein Formular mit einem DBGrid auf IBDataset und rufe MDI-Fenster mit Datensätzen aus Untertabellen zur Haupttabelle auf. Wie kann ich Commit aufrufen, ohne den Hauptdatensatz zu verlieren ? Bookmark funktioniert nur nach Lust und Laune !

Gruß Günte

[Andreas Tengicki]

Hallo,

wenn Gesine und Andreas schon so diffus von Nebenwirkungen sprechen, ist das konkretisierbar.

zu Günther: CommitRetaining

[Andreas Kosch]

Hallo Namensvetter :-)

diese Nebenwirkungen äußern sich so: Angenommen, es werden Tabellen mit sehr vielen Datensätzen (>10 000) verwendet und die Transaktionen nur mit CommitRetaining beendet. Im Laufe der Zeit wird die Anwendung immer langsamer, erst nach einem vollständige Backup- und Restore-Zyklus ist die Datenbank wieder schnell wie am Anfang (um im Laufe der Zeit wieder langsamer zu werden). Der Grund dafür liegt in der Multigenerationen-Architektur (OIT und OAT laufen auseinander, so dass der InterBase eine immer grösser werdende Kopie des Transaktionsverzeichnisses mitführen muss; Garbage Collector kann nicht anspringen etc.). Erst ein Hard commit entfernt diese Blockade.

In meinen InterBase+IBX-Buch liest sich das auf der Seite 348 so: "<i>Es ist daher immer eine gute Idee, in regelmässigen Abständen Commit (Hard Commit) anstelle von CommitRetaining aufzurufen. Das Beispielprojekt RedSys2 aus dem nächsten Kapitel demonstriert auch diese Technik</i>". <br>
Das zitierte Beispielprojekt kann hier im Forum im Ordner <i>Delphi | IBX | RedSys</i> heruntergeladen werden.

[Andreas Tengicki]

Jau fein,

aber dann müßte es doch reichen große Transaktionen (Batchbetrieb) mit Commit abzuschließen und Bildschirm Transaktionen (Benutzer, also kleine) mit CommitRetaining. Oder

[Andreas Kosch]

Hallo Andreas,

ja - genau das habe ich in meiner Beispielanwendung RedSys2 auch gemacht. Wenn die "Übersichtsformulare" (TDBGrid) offen sind, nutze ich CommitRetaining und erst dann Commit, wenn das Formular geschlossen wird. Nur beim Hauptfenster nutze ich IdleTimer, um ein Commit (Hard Commit) abzusetzen und dann die Datenmenge neu zu öffnen und zu positionieren.

Im Datenmodul verwende ich den folgenden Kommentarblock, der die Situation beschreibt:
<pre>
{
Eine der Grundregeln in der C/S-Welt lautet, dass der Client niemals
die Zeitdauer einer Transaktion bestimmen darf. Dabei muss der Entwickler
gleich 2 Fälle betrachten:
a) Transaktionsdauer bei INSERT/UPDATE/DELETE (X-Locks)
b) Transaktionsdauer bei SELECT (S-Locks)
Die Schreibzugriffe verursachen ein X-Lock (Exklusive Sperre), daher
muss die Zeitdauer dieser Sperre (= Gültigkeitsdauer der Transaktion)
minimiert werden.
Die Lesezugriffe verursachen ein S-Lock (Gemeinsame Sperre), wobei dank
der Multigenerationenarchitektur des InterBase dies nicht so gravierende
Folgen wie ein lange wirksamer X-Lock hat. Allerdings sollte auch hier
die Zeitdauer der Transaktion so kurz wie möglich sein. Was bei der BDE
kein Thema war (dank AUTOCOMMIT und der Intelligenz von TTable/TQuery),
kommt bei IBX mit dem Dringlichkeitsvermerk auf die Tagesordnung. Bei
IBX muss sich der Entwicklungs um alles selbst (!) kümmern, d.h. er
hantiert direkt mit den InterBase-Transaktionen. Und da sogar ein einfacher
Lesezugriff (SELECT) nur im Kontext einer Transaktion ausgeführt werden
kann, gibt es ein Problem. Um dieses zu lösen, gibt es mehrere Möglichkeiten:
a) Verzicht auf TDBGrid, Daten werden nur gelesen, in TEdits kopiert und
danach die Transaktion über COMMIT beendet. IBX schliesst darauf alle
aktiven Datenmengen (was hier nicht zum Problem wird).
b) Verzicht auf TDBGrid kommt nicht in Frage, daher wird die Datenmenge
sofort in eine In-Memory-Table (TClientDataSet oder ähnliches)
kopiert und danach die Transaktion über COMMIT beendet. IBX schliesst
darauf alle aktiven Datenmengen (was hier nicht zum Problem wird).
Allerdings steigt der Aufwand, wenn die Daten auch editierbar sein
sollen (Briefcase-Modell).
c) Verzicht auf TDBGrid kommt nicht in Frage, Mehraufwand für In-Memory-
Tabellen kommt nicht in Frage. In regelmässigen Abständen wird
CommitRetaining aufgerufen - wobei IBX die Datenmenge offen hält und
sich die aktuellen Datensatzposition nicht ändern.
d) Verzicht auf TDBGrid kommt nicht in Frage, Mehraufwand für In-Memory-
Tabellen kommt nicht in Frage. In regelmässigen Abständen wird
Commit aufgerufen - wobei IBX die Datenmenge jedoch schließt. Wenn
nach dem erneuten Öffnen der Datenmenge die "alte" Position sichtbar
sein soll, muss dieser Datensatz vorher über ein eindeutiges Merkmal
gespeichert werden.
Das Programm soll sich generell den vom Bearbeiter zuletzte aufgerufenen
Beitrag merken und diesen Datensatz beim nächsten Start sofort wieder
anzeigen. Es liegt auf der Hand, diese Funktion auch für die Lösung des
Transaktionsproblems zu nutzen:
1. TIBTransaction-Eigenschaft IdleTimer: Immer dann auf 10000 Millisekunden
setzen, wenn die Datenmenge IBDSBeitrag im State dsBrowse ist,
anderenfalls den IdleTime über die Zuweisung von 0 deaktivieren
2. TIBTransaction-Eigenschaft DefaultAction: TACommit -> IBX schließt dabei
automatisch alle zu diesem Zeitpunkt offenen Datenmengen, die dieser
TIBTransaction-Instanz zugewiesen waren.
3. TIBTransaction-Ereignis OnIdleTimer auswerten: Datenmengen neu öffnen und
alten Datensatz über die Primärschlüsselwerte suchen
}
</pre&gt