Problem mit COMMIT / ROLLBACK
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Warum ich Clustertabellen nehme? Weil ich "irgendwas" an Daten habe, die zum Protokoll gehören. Ein Datensatz, den ich verbuchen will (und der je nach Buchung mal die eine, mal die andere Struktur hat), Inhalte aus einer Ausnahme, etc. Klar kann ich das alles transient im Speicher halten. Und wenn irgendwas dumpt, sind alle Protokolldaten weg, die ich nicht weggespeichert habe und ich weiß genau nichts. Darum speichere ich jede Meldung einzeln weg, was einen COMMIT bedingt, der aber nicht für meinen (noch nicht komplett durchgebuchten) Geschäftsprozess gilt. Da kommt der COMMIT erst als Letztes. Zusammen mit einer Erfolgsmeldung im Protokoll (oder eben einer Fehlermeldung).ewx hat geschrieben:Was hindert dich denn daran, den { Commit | Rollback } auszuführen und danach die Daten in deine (ich frag lieber nicht, warum du eine) Clustertabelle (nimmst...) zu schreiben?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Ich hatte Clustertabellen mit Pooltabelle verwechselt... 
Ein Dump ist in der Regel ein Programmierfehler.
Deswegen werden dir m.M.n. die Protokolldaten in den wenigsten Fällen helfen.
Wenn du ansonsten nicht tonnenweise Daten speicherst, eigenen sich auch Log-points.
Bei Clustertabellen hast du den Nachteil, dass du immer genau mit den Datenstrukturen zugreifen musst, die auch beim Lesen verwendet wurden. Insofern würde ich diese Lösung präferieren: Serialisierung
Ein Dump ist in der Regel ein Programmierfehler.
Deswegen werden dir m.M.n. die Protokolldaten in den wenigsten Fällen helfen.
Wenn du ansonsten nicht tonnenweise Daten speicherst, eigenen sich auch Log-points.
Bei Clustertabellen hast du den Nachteil, dass du immer genau mit den Datenstrukturen zugreifen musst, die auch beim Lesen verwendet wurden. Insofern würde ich diese Lösung präferieren: Serialisierung
Zuletzt geändert von ewx am 03.12.2018 13:46, insgesamt 1-mal geändert.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Natürlich ist das ein Programmierfehler, aber trotzdem möchte ich gern wissen, was zu diesem Programmierfehler geführt hat. Da ist es schon sinnvoll, zu wissen, wie die Datenkonstellation ausgesehen hat (z. B. die Daten, die ich versuche auf die DB zu schreiben oder was auch immer). Bei uns ist es in der Regel (!!!) so, dass wir kaum debuggen oder Fälle nachstellen, sondern ins Protokoll gucken und wissen, was los ist. Gerade bei Hintergrundprogrammen ist das sinnvoll. Ja, für Performancemessungen gibt es andere Möglichkeiten (insofern war das Beispiel schlecht), aber wir schreiben halt (zumindest während der Entwicklungs- und Testphase) so ziemlich jeden Programmzustand ins Log.ewx hat geschrieben:Ich hatte Clustertabellen mit Pooltabelle verwechselt...
Ein Dump ist in der Regel ein Programmierfehler.
Deswegen werden dir m.M.n. die Protokolldaten in den wenigsten Fällen helfen.
Wenn du ansonsten nicht tonnenweise Daten speicherst, eigenen sich auch [urlhttps://www.tricktresor.de/blog/log-points-zur- ... cemessung/]Log-points[/url].
Bei Clustertabellen hast du den Nachteil, dass du immer genau mit den Datenstrukturen zugreifen musst, die auch beim Lesen verwendet wurden. Insofern würde ich diese Lösung präferieren: Serialisierung
Ich brauche keine andere Herangehensweise, Enno, ich brauche eine Lösung für mein Problem
Und das Problem ist: Ich möchte Logeinträge unabhängig vom eigentlichen Prozess (der eigentlichen LUW, die meinen Geschäftsprozess widerspiegelt) committen können.Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wenn das eine nicht geht, dann ist eine andere Herangehensweise angebracht.
Du hast zu den gemachten Lösungsvorschlägen noch keine Stellung genommen.
Du hast zu den gemachten Lösungsvorschlägen noch keine Stellung genommen.
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Weil ich sie im Projektteam noch diskutieren muss -- mit APC scheint sich einer von uns auszukennen. Scheint recht aufwendig zu sein (so auf den ersten Blick), aber wenn es funktioniert.....ewx hat geschrieben:Wenn das eine nicht geht, dann ist eine andere Herangehensweise angebracht.
Du hast zu den gemachten Lösungsvorschlägen noch keine Stellung genommen.
Ich bin für jeden Tipp dankbar, der uns weiterhilft. Ob einer weiterhilft, wird sich wahrscheinlich morgen zeigen, wenn ich beim Kunden bin.
Gruß
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Natürlich ist das sinnvoll.ralf.wenzel hat geschrieben: Natürlich ist das ein Programmierfehler, aber trotzdem möchte ich gern wissen, was zu diesem Programmierfehler geführt hat. Da ist es schon sinnvoll, zu wissen, wie die Datenkonstellation ausgesehen hat (z. B. die Daten, die ich versuche auf die DB zu schreiben oder was auch immer).
Nenne mir doch mal bitte ein konkretes Beispiel, bei dem die vorher protokollierten Daten geholfen haben, einen Shortdump zu beheben?
Wenn irgendwo ein Shortdump erzeugt wird, dann muss ich die Ursache dafür abfangen und eine entsprechende Exception werfen.
Wenn du speziell DB-relevante shortdumps meinst (INSERT_DUPREC etc), dann reicht es, die zu schreibenden Daten der Exception mitzugeben.
Da ist es ziemlich irrelevant, was vorher passiert ist.
Natürlich ist es wichtig zu wissen, wie die Datenkonstellation so falsch erzeugt werden konnte, dass es irgendwo dumpt, aber dafür muss man dann Prüfungen an anderen Stellen einbauen.
Da verstehe ich die Anforderung, "nebenbei" ein Protokoll laufen zu lassen.
PS: Habe grad gesehen, dass black_adept die Idee mit den messaging channel auch schon hatte... sorry! #ZweiDoofeEinGedanke.
PSS: Dele hatte auch den Vorschlag einer Dateiprotokollierung. Wenn du die Serialisierung verwendest, kannst du komplexe Datenobjekte auch in eine Textdatei schreiben (XML)...
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Habe ich gerade nicht zur Hand, weil ich mit meinem Kopf gerade woanders bin, tut mir leid. Fakt ist, dass es ärgerlich ist, wenn bei einem Dump die Protokolldaten weg sind, weil ich keinen Commit machen konnte.ewx hat geschrieben:Nenne mir doch mal bitte ein konkretes Beispiel, bei dem die vorher protokollierten Daten geholfen haben, einen Shortdump zu beheben?
Wir haben alles kompakt in der SLG1, ich sehe die Fehlermeldung und unter "Details" die Daten, die zum Fehler geführt haben. Da muss ich nicht erst in irgendeine externe Datei gucken, in der ich dann gucken muss, zu welchem Fehler welche Daten gehören.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wie?ralf.wenzel hat geschrieben: Wir haben alles kompakt in der SLG1, ich sehe die Fehlermeldung und unter "Details" die Daten, die zum Fehler geführt haben.
Ich nehme an, dass ihr eine Art Transaktions-ID mitführt und die Cluster-Protokolldaten dann auch unter dieser Nummer verwaltet?
Im SLG1-Callback zur Meldung sucht ihr euch dann die entsprechenden Daten zur ID aus dem Cluster?
Wenn ja, dann könnt ihr genauso eine Datei mit der entsprechenden ID auslesen...
Zuletzt geändert von ewx am 04.12.2018 09:39, insgesamt 1-mal geändert.
Hallo Ralf.
Seit einigen Releases hat der BAL_DB_SAVE zwei neue Parameter:
Kommst Du damit vielleicht weiter?
Grüße,
Haubi
Seit einigen Releases hat der BAL_DB_SAVE zwei neue Parameter:
- I_2TH_CONNECTION
- I_2TH_CONNECT_COMMIT
Kommst Du damit vielleicht weiter?
Grüße,
Haubi
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Oh, das sehe ich mir mal an.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Das ist mir auch aufgefallen, als ich das Beispiel mit AMC aufgebaut habe...Haubi hat geschrieben: Seit einigen Releases hat der BAL_DB_SAVE zwei neue Parameter:
- I_2TH_CONNECTION
- I_2TH_CONNECT_COMMIT
Das war wohl übrigens ein native speaker, der das eingebaut hat, mit seinem "2th"...
Wenn Du "native German speaker" meinst bin ich dabei...ewx hat geschrieben: Das war wohl übrigens ein native speaker, der das eingebaut hat, mit seinem "2th"...
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Secondthewx hat geschrieben:Das war wohl übrigens ein native speaker, der das eingebaut hat, mit seinem "2th"...
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Gerade geschehen. APC und AMS scheitern am Relesasestand, der bei uns zu niedrig ist (es gibt eine Reihe von Gründen, warum sich das nicht kurzfristig ändern lässt), ich teste mal das mit der 2. DB-Verbindung (wobei der Tipp von Haubi nicht weiterhilft, weil der nicht bis zum BAL Cluster reicht).ralf.wenzel hat geschrieben:Weil ich sie im Projektteam noch diskutieren muss
Ralf
Nachtrag: EXPORT TO DATABASE geht nicht auf einer zweiten DB-Connection.....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Würde es (releasetechnisch) vielleicht mit einer Serialisierung funktionieren?ralf.wenzel hat geschrieben:Nachtrag: EXPORT TO DATABASE geht nicht auf einer zweiten DB-Connection.....
CALL TRANSFORMATION ID ... RESULT XML (in STRING oder XSTRING)
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Vergleichbare Themen
6
Antw.
Antw.
6625
Views
Views
Commit und Rollback, auch bei RFC und BAPI
von m.schwertle » 21.11.2007 08:23 • Verfasst in ABAP® für Anfänger
von m.schwertle » 21.11.2007 08:23 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
4075
Views
Views
Sperrobjekte: Freigeben von Sperren bei Commit/Rollback ?
von MNordlicht » 09.12.2005 13:25 • Verfasst in ABAP® Core
von MNordlicht » 09.12.2005 13:25 • Verfasst in ABAP® Core
11
Antw.
Antw.
7808
Views
Views
2
Antw.
Antw.
1915
Views
Views
1
Antw.
Antw.
1955
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.