Firebird Transaction lange offen

[Gruber_Hans_12345]

Hallo

Ich wollte mal fragen, mit welchen Parametern ist es sinnvoll eine Transaktion zu starten die nur lesen ist, aber dafür sehr lange offen sein kann.
Speziell für Auswertungen eben (Reports, Pivot usw)

Ich möchte damit eben mein System nicht verlangsamen, meine schreibenden und sonstigen Transactionen sind immer extrem kurz, nur eben diese können teils auch mal tage offen beleiben (sollte nicht sein, aber es kann passieren)

Zugriff ist noch per IBX

besten danke

[mkinzler]

Warum muss dann die Transaktion tagelang offen bleiben?

[Gruber_Hans_12345]

müssen nicht aber es passiert halt

Das sind zum teil fremdkomponenten die auf die Datenbank zugreifen, und eben die Daten direkt aus der TIBQuery auslesen, und es muss bei IBX die Transaktion offen bleiben, sonst sind ja die Daten weg.

Daher müsste ich entweder eine zwischenschicht einführen, die die daten kopiert, oder die Komponente müsste sich die Daten selber kopieren.

Es handelt sich hier im Report Builder, und eine Pivot Komponente - und wenn der user eben die Fenster offen lässt bleibt auch die Transaktion offen.

[Perlsau]

Ich vermute stark, du verwechselst hier was: Nicht die Transaktion bleibt offen, sondern das Query bleibt aktiv (Active = True). Die Transaktion kann gar nicht offenbleiben, nachdem die Daten via select von der Datenbank angefordert wurden und eingetroffen sind. Wäre die Transaktion noch offen, würde der Select-Befehl noch auf seine Ausführung warten.

Eine Query- oder Table-Komponente muß aktiv bleiben, solange die Daten angezeigt oder sonstwie verarbeitet werden sollen. Anders ausgedrückt: Wenn das Property Active der Datenmenge nicht mehr den Status True aufweist, besteht keine Möglichkeit, die Datenmenge zu verarbeiten. Erst das Setzen von Active auf True bzw. der Open-Befehl führt den Select-Befehl aus und beendet damit die Transaktion.

[hstreicher]

Die Antwort lautet :

Firebird hat dafür die "Read Only" Transaction

http://www.firebirdsql.org/refdocs/l...set-trans.html

http://de.slideshare.net/ibsurgeon/3...ansactionswork

mfg Hannes

[mkinzler]

Ich würde die Daten clientseitig cachen.

[Gruber_Hans_12345]

Zitat:

Zitat von Perlsau (Beitrag 1317842)

Ich vermute stark, du verwechselst hier was: Nicht die Transaktion bleibt offen, sondern das Query bleibt aktiv (Active = True). Die Transaktion kann gar nicht offenbleiben, nachdem die Daten via select von der Datenbank angefordert wurden und eingetroffen sind. Wäre die Transaktion noch offen, würde der Select-Befehl noch auf seine Ausführung warten.

Eine Query- oder Table-Komponente muß aktiv bleiben, solange die Daten angezeigt oder sonstwie verarbeitet werden sollen. Anders ausgedrückt: Wenn das Property Active der Datenmenge nicht mehr den Status True aufweist, besteht keine Möglichkeit, die Datenmenge zu verarbeiten. Erst das Setzen von Active auf True bzw. der Open-Befehl führt den Select-Befehl aus und beendet damit die Transaktion.

Meines wissens nicht

denn ich habe ja ne TIBQuery und ne TIBTransaction, und sobald ich die TIBTransaction schleiße sind auch die daten aller zugehörigen IBQuerys oder IBTables weg.
Und auch am Firebird Server kann ich mir ja die offenen Transaction anschauen und sehe, das es eigentlich so ist.

@mkinzler
Ja Clientseitig cachen ist ne möglichkeit, und mache ich bei meinen eigenen Sachen auch, nur für die Drittanbieter Software wird es halt um einige schwieriger, und aufwändiger, und ich erhoffte mir eine schneller und fast genau so gute lösung.

@hstreicher
Aber wenn eine Transaction READ ONLY ist, dann beudetet das ja nicht, das die Records nicht trotzdem Versioniert werden müssen solange die Transaction offen ist oder?
eventuell eine kombination mit READ COMMITTED oder [NO] RECORD_VERSION

nur ich will auf keinen Fall etwas verschlimmbessern

[mkinzler]

Mit einem Clientdataset o.ä. sollte das kein Problem sein.

[Perlsau]

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1317854)

Meines wissens nicht, denn ich habe ja ne TIBQuery und ne TIBTransaction, und sobald ich die TIBTransaction schleiße sind auch die daten aller zugehörigen IBQuerys oder IBTables weg.

Mit "sobald ich die TIBTransaction schleiße" meinst du vermutlich, das Property Active der TIBTransaction auf False setzen? Die Komponente TIBTransaction ist nicht die Transaction, sondern verwaltet Transaktionen. Natürlich muß die Transaktions-Komponente so lange aktiv bleiben, wie die von ihr abhängigen Queries aktiv sind, damit sie auf Anforderungen reagieren kann.

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1317854)

Und auch am Firebird Server kann ich mir ja die offenen Transaction anschauen und sehe, das es eigentlich so ist.

Das würde mich jetzt interessieren: Wo genau siehst du am Firebird-Server die offenen Transaktionen?

[Gruber_Hans_12345]

Zitat:

Zitat von Perlsau (Beitrag 1317858)

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1317854)

Meines wissens nicht, denn ich habe ja ne TIBQuery und ne TIBTransaction, und sobald ich die TIBTransaction schleiße sind auch die daten aller zugehörigen IBQuerys oder IBTables weg.

Mit "sobald ich die TIBTransaction schleiße" meinst du vermutlich, das Property Active der TIBTransaction auf False setzen? Die Komponente TIBTransaction ist nicht die Transaction, sondern verwaltet Transaktionen. Natürlich muß die Transaktions-Komponente so lange aktiv bleiben, wie die von ihr abhängigen Queries aktiv sind, damit sie auf Anforderungen reagieren kann.

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1317854)

Und auch am Firebird Server kann ich mir ja die offenen Transaction anschauen und sehe, das es eigentlich so ist.

Das würde mich jetzt interessieren: Wo genau siehst du am Firebird-Server die offenen Transaktionen?

primitv so, (halt noch paar links dazu ... )

Code:

SELECT * FROM MON$TRANSACTIONS

ja meine wenn ich die TIBTransaktion.Active auf False setzte bzw. mit einem Transaction.Commit oder so, wenn ich ein CommitRetaining mache, dann bleiben daten erhalten, aber die Transaktion auch offen

[tsteinmaurer]

Read-Only, Read Committed. Transaktionen in dieser Kombination können lange offen bleiben. Read Committed gibt dir halt keine stabile Ergebnismenge bei mehrmaligen Ausführen einer Abfrage, aber das mußt du wissen, ob das für deinen Anwendungsfall Ok ist.

[Gruber_Hans_12345]

Zitat:

Zitat von tsteinmaurer (Beitrag 1317862)

Read-Only, Read Committed. Transaktionen in dieser Kombination können lange offen bleiben. Read Committed gibt dir halt keine stabile Ergebnismenge bei mehrmaligen Ausführen einer Abfrage, aber das mußt du wissen, ob das für deinen Anwendungsfall Ok ist.

Ok danke mal

dh. alle andern die nicht "Read Committed" sind dürfen nicht lange offen bleiben? (dürfen -> damit nicht ein haufen Record Versionen entstehen und das system langsamer wird)

bewirkt ein Read Only eignetlich eine besserung abgesehen davon das ich halt nicht schreiben kann?

[tsteinmaurer]

Es ist die Kombination aus Read Committed UND Read-Only. Generell sollte man Read-Only Transaktionen verwenden, wenn nur gelesen wird. So teilt man das Firebird entsprechend mit und Firebird weiß dann für konkurrierende Transaktionen, d.h. hier keine Datenänderungen zu erwarten sind.

[Gruber_Hans_12345]

Also habe ich nur die möglichkeit für Reports
- entweder normal, dann habe ich richtige Daten aber die Transaktion sperrt die ganze zeit
- READONLY read committed, dann sperrt nix, aber die daten können falsch sein, wenn ich vor/zurückblättere
- Umbau auf Cachen der Daten

[tsteinmaurer]

Was verstehst du unter "Sperren"?

[Gruber_Hans_12345]

Zitat:

Zitat von tsteinmaurer (Beitrag 1317884)

Was verstehst du unter "Sperren"?

Das die Datenbank dann mit der zeit langsamer wird, weil der Garbage Collector nicht laufen kann, und die Records immer Versioniert werden müssen ...

[tsteinmaurer]

Wenn du das unter Sperre verstehst, dann hast du vollkommen Recht.

[himitsu]

Warum überhaupt eine Transaktion?

"Ein" SELECT ist in sich geschützt, vor fremden Schreibzugriffen.

[mkinzler]

Das hat hat mit der Art und Weise zu tun wie FireBird die Transaktionssteuerung durchführt. Anstatt eines Logs wird Versionierung verwendet. Deshalb müssen auch Abfragen in einem Transaktionskontext erfolgen (zur Feststellung welche Version des Datensatzes genommen werden soll).

[Gruber_Hans_12345]

Zitat:

Zitat von himitsu (Beitrag 1317894)

Warum überhaupt eine Transaktion?

"Ein" SELECT ist in sich geschützt, vor fremden Schreibzugriffen.

weil zumindest bei IBX ohne Transaktion gar nix geht ....

[tsteinmaurer]

In Firebird geht nix ohne den Kontext einer Transaktion

[BUG]

Zitat:

Zitat von tsteinmaurer (Beitrag 1317927)

In Firebird geht nix ohne den Kontext einer Transaktion

Alles andere wäre ja auch Blödsinn ... wer will denn inkonsistente Daten aus einer Datenbank lesen. Schreibenden Zugriffen außerhalb von Transaktionen würden es unmöglich machen, Transaktionen überhaupt zu implementieren.

Zitat:

Zitat von himitsu (Beitrag 1317894)

"Ein" SELECT ist in sich geschützt, vor fremden Schreibzugriffen.

Jup, weil es in einer einzelnen Transaktion läuft :stupid:

Zitat:

Zitat von Gruber_Hans_12345 (Beitrag 1317867)

bewirkt ein Read Only eignetlich eine besserung abgesehen davon das ich halt nicht schreiben kann?

Es kann halt keine Schreibkonflikte mit anderen Transaktionen geben; mehrere nur-lesende Transaktionen beeinflussen einander gar nicht. Also, wenn das nichts wert ist.

[Sir Rufo]

Interessant dazu folgender Eintrag in der Doku
http://docwiki.embarcadero.com/Libra...ions.Isolation

[tsteinmaurer]

Nur zur Info. Firebird unterstützt keine Dirty Reads. Gott sei Dank.