gelöst Ist Timeout-Verlängerung mit ROLLBACK WORK möglich?

[DeathAndPain]

Hallo zusammen,

es ist ja relativ bekannt, dass sich ein im Vordergrund laufendes Programm unbegrenzt Rechenzeit erschleichen kann, indem es regelmäßig einen COMMIT WORK absetzt. Ich habe jetzt einen Fall, in dem ich im Falle eines lang laufenden Testlaufes keine Änderungen auf der Datenbank verewigen möchte. Frage: Wenn jener Testlauf regelmäßig einen ROLLBACK WORK absetzt, bekommt er dann auch unbeschränkt Rechenzeit?

Vielen Dank!

[ralf.wenzel]

Also, du solltest dich mal damit auseinandersetzen, was an beiden Anweisungen so alles dranhängt, dann weißt du, dass auch ein COMMIT die schlechteste aller Möglichkeiten ist. Zudem bin ich entsetzt, dass gerade du dich solcher Methoden zulasten aller anderen auf dem System bedienen willst, deinen Dialog-Prozess am Laufen zu halten. Um es deutlich zu sagen: Wer soll denn einen Entwickler ernst nehmen, der sich solcher Frickelei bedient? Gestern habe ich einen mit Ducktape („Panzerband“) geklebten Mercedes gesehen (Kotflügel angeklebt), so etwa wirkt das auch.

Nimm wenigstens den SAPGUI Progress Indikator, wenn du dich solch zweifelhafter Mittel schon bedienen willst (was meist nicht notwendig ist). Aber selbst in unserem OO-basierten Modul für Blutspendedienste, das unter Berücksichtigung der enormen Datenmengen eigentlich sehr langsam sein müsste (wenn man deinen Ausführungen folgt) hatten wir solche Aktionen nicht nötig.


Ralf

[black_adept]

Also, du solltest dich mal damit auseinandersetzen, was an beiden Anweisungen so alles dranhängt, dann weißt du, dass auch ein COMMIT die schlechteste aller Möglichkeiten ist.

Ok - D&P hat die Vorgabe ein lang laufendes Programm irgendwie trotzdem onlinefähig zu bekommen. Da COMMIT die schlechteste Möglichkeit zu sein schein, scheinst du noch andere allgemeine Möglichkeiten zu kennen das Problem zu lösen, da du ja D&Ps Rahmenbedingungen nicht kennst. Magst du uns nicht mal aufhellen wie das noch gehen könnte, so dass wir alle davon lernen können?

[ralf.wenzel]

Da er nichts anderes geschrieben hat, gehe ich davon aus, dass das Programm von ihm selbst ist. Und dann liegt der Designfehler bei ihm selbst, dann sollte er sich was einfallen lassen, warum das so lange läuft (er scheint ja über Laufzeiten und deren Ursache einiges zu wissen.

Man kann Vieles machen, wenn man das Programm kennt. Das ist bei mir nicht der Fall. COMMIT WORK ist einfach, aber normalerweise nicht notwendig und arbeitet zum Schaden anderer. Ich hab z. B. schon Teile von Programmen in den Hintergrund verlagert. Das wäre ggf. eine Alternative, die in jedem Falle besser ist.

Ralf

[black_adept]

@Ralf
Ok - das wären schon mal Ansätze. Aber es gibt immer mal wieder Situationen, wo es einfach nicht geht ein Programm noch weiter zu beschleunigen aber die Anforderung trotzdem so ist, dass es online laufen soll und der Entwickler kein Trottel ist, der einfach zu dumm ist das Programm schneller zu machen.
Davon abgesehen - die Frage war "Wie kann ich ein lang laufendes Programm online halten ohne Dump" und die Antwort "mach das Programm schneller" inkl. "dafür gibt es viele Möglichkeiten" beantworten die Frage halt nur unter der Prämisse, das es tatsächlich möglich ist das Programm schneller zu machen.
Aber wenn das mal nicht der Fall ist - was dann? Deine Originalantwort impliziert hier diverse andere Möglichkeiten.

@D&P & Ralf
Ich kenne aktuell lediglich 2 Möglichkeiten den Dump zu verhindern.

• COMMIT WORK ( evtl. auch ROLLBACK - das habe ich aber noch nie probiert ) inkl. der damit verbundenen Nebeneffekte (z.B. Lösen von Sperren )
• Anmeldung an einem speziell für solche Zwecke vorgesehenen Anwendungsserver, der ein VIEL! längeres Timeout hat und "AufDieFingerHauen" bei jedem Anwender, der sich hier anmeldet für "normale" Aufgaben. Aber auch hier - nur möglich wenn es mehrere Anwendungsserver gibt bzw. die Basis bereit ist einen solchen "Langlaufserver" bereit zu stellen.

[ralf.wenzel]

Solche Andorderungen sind sehr, sehr selten und zumeist technisch fehlerhaft. Und selbst dann gibt es bessere Möglichkeiten.

Eine Möglichkeit habe ich genannt: Progress Indikator. Soweit ich weiß, hilft der auch.


Ralf

[black_adept]

Eine Möglichkeit habe ich genannt: Progress Indikator. Soweit ich weiß, hilft der auch.

Bitte ausprobieren - das hängt vom System ab. ( -> https://archive.sap.com/discussions/thread/1620838.
Aber wenn es den Counter auf eurem System zurücksetzt ist das definitiv dem COMMIT vorzuziehen wie schon von Ralf gesagt.
Alternativ wird in dem o.a. Thread der FuBa TH_REDISPATCH angesprochen, der das angeblich auch tun soll..

[ralf.wenzel]

Den FuBa kenne ich, aber solange ich nicht ganz genau weiß, was der wie tut, rühre ich den nicht an.

Ralf

[larsi]

Hallo zusammen,

es ist ja relativ bekannt, dass sich ein im Vordergrund laufendes Programm unbegrenzt Rechenzeit erschleichen kann, indem es regelmäßig einen COMMIT WORK absetzt. Ich habe jetzt einen Fall, in dem ich im Falle eines lang laufenden Testlaufes keine Änderungen auf der Datenbank verewigen möchte. Frage: Wenn jener Testlauf regelmäßig einen ROLLBACK WORK absetzt, bekommt er dann auch unbeschränkt Rechenzeit?

Vielen Dank!

Ich habe mir bislang immer mit der Klasse CL_SWF_UTL_TIMEOUT_SERVICE beholfen - die erreicht das nämlich ohne Verwendung von COMMIT WORK oder ROLLBACK. In einem eigenen Programm hätte ich aber auch keine Schmerzen, dies durch einen COMMIT WORK zu erreichen. In der Hilfe ist ja gut beschrieben, was alles bei einem COMMIT WORK passiert - und wenn mein Programm so gestrickt hast, dass all diese Sachen für mein kein Problem darstellen - so what? Das Problem mit den Sperren lässt sich ja durch geschicktes Wählen des "_SCOPE"-Parameters auch umgehen, um diese damit über den COMMIT WORK hinaus zu behalten.

Viele Grüße
Lars

[DeathAndPain]

Erst mal vielen Dank für die Antworten.

@Ralf: Das Programm ist nicht von mir, aber ich habe es vor einigen Jahren von der externen Beraterfirma, die es einst programmiert hat, geerbt und betreue es seitdem. Es berechnet die Datenausgabe an einen externen Lohndatenabrechner. Zu diesem Zweck rennt es durch den ganzen Personalstamm und berechnet für jeden Mitarbeiter die auszugebenden Daten. Dabei muss es Stammdaten, Zahlungsdaten, Abwesenheitsdaten usw. ausgeben mit der Maßgabe, dass nur Daten ausgegeben werden sollen, die sich seit dem letzten Lauf geändert haben, so dass ein umfangreiches Logging der eigenen Ausgabe erforderlich ist. Bei vielen Daten ist dabei noch Detailcoding vorhanden. Das Ganze hat einen erheblichen Komplexitätsgrad.

Der Code war sehr mies strukturiert. Es handelt sich um ein OO-Programm, bei dem das OO darin besteht, dass ein einziges Objekt erzeugt wird und im Constructor der gesamte Nutzcode steht. Anstelle von Formroutinen werden lokale Methoden verwendet. That's OO for you. Auch sonst fand ich den Code alles andere als dolle, und gerade angesichts der Komplexität des Ganzen ist gute Strukturierung durchaus wichtig. Deswegen habe ich den Code grundlegend überarbeitet, musste dabei aber immer vorsichtig sein, denn es ist aus offensichtlichen Gründen (Gehälter sind in HR das Herzblut) ein sehr kritischer Report, der funktionieren muss, was er inzwischen auch ganz gut tut.

Du wirst lachen: Eine Hintergrundverarbeitung habe ich vor zwei Jahren oder so auch eingebaut, nebst der Möglichkeit, auf die Ergebnisse früherer Programmläufe zuzugreifen und sich die (geloggten) Ergebnisse derselben zu ziehen. Dies ist notwendig, da die Sachbearbeiter das Programm händisch starten und die Ergebnisdateien auf ihre lokalen PCs herunterziehen. Bei einem im Hintergrund, also ohne GUI, laufenden Programm geht das nicht, und meine Lösung besteht halt darin, dass sie nach Ende des Programmlaufs dieses erneut im Vordergrund starten und dann das zuvor berechnete Ergebnis herunterladen können. Hat nebenbei auch den Vorteil, dass bei ihnen nicht ewig ein SAPGui-Modus blockiert ist und sie nicht von vorne rechnen müssen, wenn mal nach erfolgten Berechnungen die Datenübertragung von Server zu SAPGui auf die Nase fällt (das hatten wir früher alles).

Über den ganzen Prozess kann man sicherlich diskutieren, aber: Never change a running system.

Die Ausführung im Vordergrund hat allerdings den Charme, dass man hinterher nicht nur csv-Dateien hat, die man sich in Excel zurechtformatieren kann, sondern auch komfortabel zwischen mehreren ALVs (einem pro Ergebnisdatei; es entstehen immer mehrere) blättern und die Daten darin durchsehen kann. Für Testläufe, also solche ohne Datenausgabe und Logging, ist dies sehr attraktiv, und im Personalwesen braucht man eigentlich immer Testläufe vor jeder Abrechnung, weil es immer irgendwelche fehlerhaften Personaldaten gibt, die man glattziehen muss, bevor man das wirklich in die Abrechnung gibt.

Um dies grundsätzlich möglich zu machen, habe ich gesagt, dann soll er im Testlauf halt regelmäßig einen COMMIT WORK machen. Da der Testlauf nichts macht, macht auch der COMMIT WORK nichts. Wir haben genug Serverleistung, und dann können die Sachbearbeiter nach einer Stunde oder wie lange das Ding läuft ihr Ergebnis anschauen. Die produktiven Daten rechnen sie dann über Nacht im Hintergrund (da will ich keine Zwischen-COMMITs haben, denn falls während des Programmlaufs irgendwas schiefgeht - und sei es, dass der Server mal abschmiert - will ich keine halb berechneten Lohnausgaben haben, da man die nie vernünftig ergänzt bekommt).

Nun musste ich aber feststellen, dass auch im Testlauf bestimmte Logänderungen vorgenommen werden, so dass Testläufe nachfolgende Produktivläufe verfälschen. Dies programmtechnisch zu ändern wäre nicht trivial, und die Gefahr wäre groß, dass ich mir bei den entsprechenden Umbauten neue Bugs einfange, die ich in diesem Programm aus offensichtlichen Gründen so gut wie möglich vermeiden möchte. Da war meine Idee, ob man das nicht einfach lösen kann, indem ich statt regelmäßiger COMMIT WORKs einfach regelmäßige ROLLBACK WORKs mache. Im Testlauf soll sich auf der Datenbank ja nichts verändern.

Mittlerweile kann ich sagen, dass ROLLBACK WORK den Timeout nicht zurücksetzt. So einfach geht es also nicht. Was ich aber jetzt im Testlauf mache, ist ein ROLLBACK WORK und gleich danach ein COMMIT WORK. Das funktioniert natürlich.

Bitte ausprobieren - das hängt vom System ab. ( -> https://archive.sap.com/discussions/thread/1620838.

Also soweit ich das diesem Thread entnehme, ging das allenfalls bis Release 7.00 und ist insofern heute keine Option mehr.

Ich habe mir bislang immer mit der Klasse CL_SWF_UTL_TIMEOUT_SERVICE beholfen - die erreicht das nämlich ohne Verwendung von COMMIT WORK oder ROLLBACK.

Also wenn ich mir diese Klasse so in der SE24 anschaue, dann kann ich das kaum glauben. Die kann man ja mit einem Blick überschauen; die besteht ja nur aus wenigen Methoden, die jeweils nur wenige Befehle enthalten. Diese Befehle kommen mir zudem noch recht sinnlos vor (vor allem die Methode ON_TIMEOUT), aber gut, die Klasse ist nicht dokumentiert; ihr Autor wird sich schon was dabei gedacht haben.

[Daniel]

TH_REDISPATCH ist genau das was du suchst.
Ich verwende den auch manchmal.

[DeathAndPain]

Vielen Dank.

@Ralf: Etwas Recherche hat ergeben, dass der Funktionsbaustein TH_REDISPATCH durchaus dokumentiert ist, und zwar in Hinweis 25528.