Analog zu AUTONOMOUS TRANSACTION

Hallo miteinander,

ich habe eine größere Import-Routine. Dabei gibt es eine Haupt-Prozedur die versch. andere Prozeduren aufruft und diese evtl. wiederum andere Prozeduren. Damit der Anwender einen Status des Imports hat, würde ich gerne während des Imports an bestimmten Stellen eine Info in eine Status-Tabelle schreiben, äh, das mache ich auch … ABER, diese Infos sehe ich erst, wenn der Import beendet ist.
Das Problem ist, dass erst das Commit der Hauptprozedur dafür sorgt, dass auch die Status-Sätze zu sehen sind.
In Oracle habe ich für dieses Problem die Anweisung AUTONOMOUS TRANSACTION für die Status-Schreib-Prozedur genutzt. D.h. diese Anweisung in dieser Prozedur werden in einer eigenen Transaktion gehandelt. Diese Anweisung gibt es in Postgres nicht, aber evtl. hat jemand eine Idee, wie ich das Problem lösen könnte?! Das wäre super.


Vielen Dank und Grüße Petra

Direkt innerhalb einzelner Transaktionen ist dies meines Wissens nicht möglich.

Als Workaround fällt mir ein: du könntest in einer (beliebigen serverseitigen) Scriptsprache eine weitere Datenbankverbindung aufbauen, die Status Daten schreiben und die Verbindung wieder schliessen. Dann hättest du getrennte Transaktionen.

Hallo ads,
d.h. statt einer proc aufzurufen, die den Status schreibt, soll ich in einer Proc ein Skript auf dem Server aufrufen, das mit einer eigenen Connection (damit auch eigener Transaktion) diese Sätze schreibt.
Habe ich das richtig verstanden?
Nur was könnte ich aus einer DB-Prozeudr aufrufen, Du schreibst etwas von einem Skript … hm, davon habe ich ja nun überhaupt keine Ahnung.
Da kommt denn auch gleich meine nächste Frage: Könnte ich z.b. eine EXE-Datei auf dem Server aus einer DB-Prozedur aufrufen? Darüber habe ich noch nie gedacht und habe auch nicht die geringste Ahnung, ob so etwas funktioniert.

ACH, wäre evtl. auch folgendes möglich:
Während des Imports rufe ich eine zweite Proc auf, die mir die Sätze aus der Status-Tabelle zurückgeben und in der Proc müßte ich den ISOLATION LEVEL AUF READ UNCOMMITED (oder so ähnlich, weiß nicht mehr genau was ich gelesen habe :slight_smile: , muss ich nochmal schauen). Dann müßte ich doch auch geänderte Sätze erhalten, die noch nicht Commited sind, oder??
Vielen Dank für Deine Antwort und Grüße Petra

Korrekt. Naja, nicht ganz. Innherhalb der laufenden TX ist das auch schon zu sehen.

In Oracle habe ich für dieses Problem die Anweisung AUTONOMOUS TRANSACTION für die Status-Schreib-Prozedur genutzt. D.h. diese Anweisung in dieser Prozedur werden in einer eigenen Transaktion gehandelt. Diese Anweisung gibt es in Postgres nicht, aber evtl. hat jemand eine Idee, wie ich das Problem lösen könnte?! Das wäre super.

Du könntest evtl. mit NOTIFY (PostgreSQL: Documentation: Manuals: PostgreSQL 8.1: NOTIFY) einen externem Prozeß etwas mitteilen, bin mir aber grad nicht sicher, ob das NOTIFY schon während der TX oder auch erst zum COMMIT kommt. Anderer Weg, wie ads schon sagte, in einer untrusted language (pl/perlU z.B., plsh scheidet bei deiner OS-Distribution wohl eher aus) etwas in eine externe Datei schreiben.

Um nur zu sehen, wie weit Du in Deiner Arbeit schon bist, könntest Du aber auch zu Begin der Sache eine Sequence erzeugen und zu bestimmten Zeitpunkten ein select nextval() drauf machen. Dann kannst Du auch außerhalb dieser TX
last_value von dieser Sequence abfragen, weil die Sequence-Manipulation selbst nicht in einer TX abläuft.


Andreas


Andreas

Vielen Dank und Grüße Petra[/QUOTE]

Ja, das hast du im Prinzip richtig verstanden.

Eine Scriptsprache, die im Server Kontext läuft, ist natürlich in der Lage, auch weitere Verbindungen unabhängig von ihrer aktuellen Verbindung zur Datenbank aufzurufen. Das liesse sich hier ausnutzen. Ob und wie das mit einer eigenen Exe Datei geht … nun, du kannst definitiv auch Erweiterungen in C schreiben, die so etwas erledigen könnten, das dürfte allerdings ein Stück aufwendiger sein als z.B. Perl, Python oder Java dafür einzusetzen.

Deine Proceduren laufen alle innerhalb einer großen Transaktion ab, so das du mit dem Wechsel des Isolationslevels (geht das überhaupt mehrfach? Grübel) nicht weiterkommen dürftest.

Hallo Andreas,

Du hast natürlich Recht, in der Transaktion, in der ich mich während des Imports befinde sehe ich natürlich die Satus-Einträge.
Aber die Anwendung wird mit einem Timer während des Import immer wieder dieses Status-Tabelle abfragen und diese Abfragen sehen die Änderungen nicht.

Die Idee mit der Sequenc ist auch nicht schlecht, damit kann ich weiterkommen, da muss ich mir mal was dazu überlegen.

Vielen Dank und Grüße Petra

Uhm, daran habe ich gar nicht gedacht. Stimmt, mit NOTIFY könnte man externen Prozessen auch Nachrichten schicken … Wenn dein Prozess, der den Status ausliest, auf das NOTIFY hört, hast du so eine einfache Möglichkeit, Infos weiterzugeben.

Danke, akretschmer.

hallo ads,
stimmt, ich glaube innerhalb einer Trnsaktion kann man den isolation level nur einmal ändern.
Aber wenn ich diese Proc ausführe, wäre ich nicht in der Import-Transaktion.
Ich hatte mal folgendes testweise eingegeben:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITED;
ABer das kennt Postgres gar nicht, hier wird das Uncommited angemeckert??! Schade, schade, wäre nicht schlecht gewesen.

Ich habe jetzt schon zwei Ansätze:

  • Skript aufrufen
  • Sequence abfragen

und das NOTIFY

DAs hilft mir auf alle Fälle schon mal weiter.
Vielen Dank und Grüße Petra

Drei, den Vorschlag mit NOTIFY würde ich mit an deiner Stelle ernsthaft anschauen.

hallo ads,
ja, und das NOTIFY werde ich mir auch anschauen.
Viele Grüße PEtra