Funktion/Methode mit Datenbank-Zugriff. Wann "Commit" ?

[Flori]

Hallo zusammen,

ich habe da mal eine Frage der Kategorie "wie macht man das am elegantesten?"

Gefragt ist eine Funktion/Methode, die von verschiedenen Programmen aus aufgerufen werden kann und quasi als "Dienstleister" fungiert.

Die Funktion soll dazu dienen, Benachrichtigungen/Ereignisse aus den anderen Programmen entgegen zu nehmen und diese dann in eine Datenbank (Oracle) zu schreiben.

Beispiel:

Ein Programm nimmt eine Datei entgegen und macht daraus das Ereignis "Datei erhalten", ein anderes archiviert diese Datei und gibt aus "Datei erfolgreich archiviert" usw...diese Ereignisse werden als Parameter an die Funktion/Methode übergeben.

Trivialerweise ruft nun jedes Programm einfach immer, wenn notwendig, die Funktion auf, um die es hier geht und schreibt das Ereignis in die Datenbank. So weit so gut...denke, so weit bin ich auch schon.

Nun mach ich mir da gerade aber Gedanken drüber, ob das so elegant ist, da man ja jedes "INSERT" in der Datenbank auch mit einem

"Commit" abschließen müßte, damit der Wert dort dauerhaft gespeichert und sofort für andere Anwendungen verfügbar ist.

Meine Frage geht also in die Richtung:

Wie kann man vermeiden, daß nach jedem "INSERT" eines Ereignisses ein "COMMIT" gemacht wird (hmm, da kommt mir gerade der Gedanke, daß

sich das COMMIT-Verhalten auch in der DB noch einstellen läßt...möchte ich aber erstmal nicht dran drehen) bzw. wie kann ich zwar die Ereignisse in der Funktion entgegen nehmen, die Anzahl der COMMITs aber möglichst gering halten?

Hat von Euch jemand schon mal eine solche Funktion/Methode geschrieben und kann mir einen "eleganten" Ansatz geben von der Funktionsweise her?

Würde mich freuen, wenn ihr hilfreiche Anregungen, Web-Links oder eigene Erfahrungen posten würdet!

Vielen Dank im Voraus!!!

Danke und Gruß

Flori

[Amstelchen]

Gefragt ist eine Funktion/Methode, die von verschiedenen Programmen aus aufgerufen werden kann und quasi als "Dienstleister" fungiert.

Die Funktion soll dazu dienen, Benachrichtigungen/Ereignisse aus den anderen Programmen entgegen zu nehmen und diese dann in eine Datenbank (Oracle) zu schreiben.

gut, dann nennen wir diese methode erstmal den "broker".

Beispiel:

Ein Programm nimmt eine Datei entgegen und macht daraus das Ereignis "Datei erhalten", ein anderes archiviert diese Datei und gibt aus "Datei erfolgreich archiviert" usw...diese Ereignisse werden als Parameter an die Funktion/Methode übergeben.

Trivialerweise ruft nun jedes Programm einfach immer, wenn notwendig, die Funktion auf, um die es hier geht und schreibt das Ereignis in die Datenbank. So weit so gut...denke, so weit bin ich auch schon.

wie schaut diese vorhandene (?) "funktion" aus - ist das eine in der DB hinterlegte prozedut oder ein einem externen programm vorhandene funktionalität?

Nun mach ich mir da gerade aber Gedanken drüber, ob das so elegant ist, da man ja jedes "INSERT" in der Datenbank auch mit einem

"Commit" abschließen müßte, damit der Wert dort dauerhaft gespeichert und sofort für andere Anwendungen verfügbar ist.

es sollte so oft COMMITed werden wie notwendig und so selten wie möglich, unter berücksichtigung der tatsache, dass unCOMMITete DMLs in den rollbacksegmenten/UNDO auflaufen.

Wie kann man vermeiden, daß nach jedem "INSERT" eines Ereignisses ein "COMMIT" gemacht wird

indem das COMMIT vermieden wird und die transaktion offengelassen wird für weitere INSERTs (UPDATEs, DELETEs).

wie kann ich zwar die Ereignisse in der Funktion entgegen nehmen, die Anzahl der COMMITs aber möglichst gering halten?

das kommt auf die besagte funktion an.

Hat von Euch jemand schon mal eine solche Funktion/Methode geschrieben und kann mir einen "eleganten" Ansatz geben von der Funktionsweise her?

bitte poste mal genaueres zu art und weise dieser funktion, die du da hast. ist das PL/SQL?

s'Amstel

[Flori]

Hallo s'Amstel,

danke schon mal für deine Antwort. Derzeit kämpf ich mich erstmal noch durch einige "Randerscheinungen" der Programmiersprache und der Software für die diese Methode sein soll.

gut, dann nennen wir diese methode erstmal den "broker".

Ok.

wie schaut diese vorhandene (?) "funktion" aus - ist das eine in der DB hinterlegte prozedut oder ein einem externen programm vorhandene funktionalität?

Diese "Broker"-Methode ist in einer separaten Datei und wird von den Programmen aus aufgerufen. Geschrieben ist/wird sie wie auch die aufrufenden Programme in der Sprache "Message Builder" (wie schon erwähnt eine eigene, propietäre 4GL-Sprache des Software-Herstellers)

es sollte so oft COMMITed werden wie notwendig und so selten wie möglich, unter berücksichtigung der tatsache, dass unCOMMITete DMLs in den rollbacksegmenten/UNDO auflaufen.

Im Umkehrschluß heißt das dann, daß je öfter man COMMITed umso mehr Einträge in meinen Redo-Logs stehen, oder?

indem das COMMIT vermieden wird und die transaktion offengelassen wird für weitere INSERTs (UPDATEs, DELETEs).

Da hätte ich weiterhin die Frage wie lange man nun eine Transaktion offen läßt. Welche Faktoren sollte/müßte/könnte man da berücksichtigen, um zu wissen wann ein COMMIT "gut tut"?

das kommt auf die besagte funktion an.

bitte poste mal genaueres zu art und weise dieser funktion, die du da hast. ist das PL/SQL?

Wie gesagt, die ProgSprache ist "Message Builder Language" (zu erklären was da jetzt hintersteckt würde wohl jeden Rahmen sprengen, sie ist von der Firma Axway, wenn das jemandem hier was sagt?).

Hier die Funktion im "Roh"-Zustand:

DECLARE PUBLIC STATEMENT DBINSERT IN $id FEHLER IN $fehler

{

   ORACLE.StatementPrepare $MyConnectId

                           STATEMENT "INSERT INTO events VALUES (" & $id & ", '" & $fehler & "')"

                           STATEMENT_ID $statementId;

   ORACLE.StatementExecute $statementId;

   ORACLE.StatementDestroy $statementId;


   RETURN;

}

Der Aufruf erfolgt von einem anderen Programm in der folgenden Art und Weise:

DBINSERT 4711 "E0815", d.h. $id=4711 und $fehler="E0815 werden übergeben und dann erfolgt zunächst mal einfach nur der Insert in die Tabelle "events"

Hier ein COMMIT würde bedeuten, daß ich jedes Insert COMMITen würde, woraus meine Fragen halt entstanden sind.

Falls das ganze hier aufgrund der eigenwilligen ProgSprache zu sehr abhebt und unerklärbar wird..vielleicht gibts ja doch ein paar allgemeine Ratschläge wie man mit dem COMMIT umgeht. Z.B. wie hast Du/habt Ihr das ganze realisiert, falls schon mal gemacht?

Danke erneut für Eure Posts!

Gruss

Flori

[Jasper]

wann und wie oft committed wird sollte man nicht von technischen fragen abhängig machen, committed wird immer so oft wie nötig. wenn 'datei erhalten' für sich eine abgeschlossene transaktion darstellt, gehört ans ende ein commit. aus vermeintlichen gründen an commits sparen zu wollen und damit die transaktion grösser zu fassen als sie es eigentlich ist, ist keine gute idee.

sollte 'datei erhalten', 'date erfolgreich archiviert' insgesamt eine transaktion darstellen und du möchtest aber im fehlerfall die einzelnen schritte zurückrollen können, setze nach jedem schritt einen savepoint und ganz am ende ein commit. so kann jeder einzelne schritt zurückgerollt werden, allerdings hilft das nicht bei einem db-ausfall, dann wird trotzdem die gesamte transaktion zurückgerollt.

-j

[Flori]

Danke Jasper,

nach meinem bisherigen Stand würde dann jedes Programm seine eigene Transaktion starten und diese dann sinnvollerweise nach einem Durchlauf abschließen.

Der Begriff Savepoint ist mir ziemlich neu. Werde mal schauen, was ich dazu finde und probieren was er mir ermöglicht.

Derzeit wird die gesamte Funktionalität jeden Tag komplexer. Muß noch einige Anforderungen auswerten. Womöglich sollte ich mich erst dann an die endgültige Ausarbeitung machen.

Werde ggfs. nachberichten.

Danke und Gruß

Flo