[Frage] Wie lange hält SELECTLATESTVERSION

Hallo Community,

Ich habe folgendes Problem. Bei einer parallelen Massenstapelverarbeitung kam es vermehrt zu merkwürdigen temporären Fehlern, die darauf schließen lassen, dass veraltete Daten aus dem Chache genutzt worden. SELECTLATESTVERSION soll ja bekanntlich helfen und tatsächlich hat das die Anzahl der Fehler stark veringert. Allerdings sind sie immer noch vereinzelt vorhanden. Es scheint also, dass die Wirkung des Befehls irgendwann aufhört und die Routine wieder auf gechachte Daten zugreift. Nun will ich aber nicht in allen Unterfunktionen irgendwo SELECTLATESTVERSION einfügen. Ich habe mich dahingehend schon immer gefragt wie lange die Wirkungsdauer des Befehls ist. Kann man das überhaupt so pauschal beantworten? Was würdet ihr vorschlagen wie ich hier vorgehe?

Grüße René

Meiner Meinung nach wird der erste (lesende) Zugriff direkt zu erneutem caching führen.

Werden also während der Verarbeitung extern Daten geändert, kann es zu diesem Verhalten kommen.

Hallo,

vielen Dank für die Rückmeldung. Das dachte ich mir leider schon. Ich werde das Problem also weiter beobachten.

Grüße René

Bei einer parallelen Massenstapelverarbeitung

Ich vermute mal ganz stark, dass genau dieser Punkt die Ursache ist.
Ihr müsst irgendwie sicherstellen, dass diese Massenstapelverarbeitungen nicht zur gleichen Zeit die gleichen Daten in die Finger bekommen.

Entweder arbeitet ihr mit Tabellensperren (die möglichst zeitnah mittels COMMIT wieder aufgehoben werden), oder ihr müsst auf andere Art und Weise sicherstellen, dass die Stapelverarbeitungen sich nicht ins Gehege kommen können.

Wenn es sich um unterschiedliche Stapelverarbeitungen handelt, die von der Aufgabenwarteschlange gestartet werden, müsst ihr die Ausführungszeiten so legen, dass sie niemals zur gleichen Zeit aktiv sind, sondern immer mindestens eine Minute zwischen dem Ende der einen und dem Start der anderen auseinanderliegen.

Ihr müsst irgendwie sicherstellen, dass diese Massenstapelverarbeitungen nicht zur gleichen Zeit die gleichen Daten in die Finger bekommen.

Entweder arbeitet ihr mit Tabellensperren (die möglichst zeitnah mittels COMMIT wieder aufgehoben werden), oder ihr müsst auf andere Art und Weise sicherstellen, dass die Stapelverarbeitungen sich nicht ins Gehege kommen können.

Wenn es sich um unterschiedliche Stapelverarbeitungen handelt, die von der Aufgabenwarteschlange gestartet werden, müsst ihr die Ausführungszeiten so legen, dass sie niemals zur gleichen Zeit aktiv sind, sondern immer mindestens eine Minute zwischen dem Ende der einen und dem Start der anderen auseinanderliegen.

Du hast richtig vermutet. Ich nutze die Aufgabenwarteschlangenposten (AWP) aber unterteile meinen Container der Massendaten in verdauliche Häppchen auf mehrere AWPs auf. Dann schreibe ich die ID des AWP an die Containerzeile, sodass ich sicher sein kann, dass 2 AWPs nicht die selbe Rechnung am Wickel haben. Nach jedem Teilschritt wird immer auch ein Commit gemacht, da Einzelschritte in Codeunit-OnRun-Trigger ausgelagert sind damit ich dort enthaltene Fehlermeldungen abkapseln kann und als Fehlerbeschreibung an meine Containerzeile schreiben kann. Es erfolgen in sehr kurzen Abständen eigentlich immer recht schnell Commits.
Oder meinst du mit "Daten" nicht den einzelnen Datensatz, sondern ganze Tabellen? Tabellensperren wollte ich eigentlich nicht so gern nutzen, da a) der Effekt der parallelen Abarbeitung dadurch ja irgendwie verloren geht und b) ich dann für einen Buchungsvorgang sehr viele Tabellen sperren müsste, was ich so noch nichtmal vollumfänglich bewerten kann, welche Tabellen aufgrund der doch umfangreichenden Anzahl da alles mit reinspielt.

Hallo,

Ich verstehe immer nicht, wie das Buchen (=> schreiben) von Daten in die gleichen Tabellen dadurch schneller wird, das man sie auf mehrere Prozesse verteilt, die man man auch noch synchronisieren muss? Im Falle der Buchungsroutinen bedeutet das auch noch, das Daten regelmäßig zwischen den Servicetiers synchronisiert werden müssen, weil mal der eine, mal der andere Prozess die letzte "Entry No." der Posten im Cache hat.

Kann mir das mal jemand erklären?

Ich könnte das ja noch verstehen, wenn es Prozesse wären, die viel bzw. nur lesen und auf unterschiedlichen Maschinen laufen. Das macht für Planungsläufe und Statistiken aus meiner Sicht sehr viel mehr Sinn, die auf unterschiedliche Aufgabenwarteschlangen zu verteilen.

Gruß Fiddi

Hallo,

naja vermutlich ist der Effekt nur theoretischer Natur, da meine Massenverarbeitung noch nicht in einer ausreichenden Produktivumgebung gelaufen ist. Das Modul ist noch recht neu und Livetests sind noch nicht in dem Umfang gelaufen um plausible Vergleichsmöglichkeiten zu haben. Theoretisch schreibt aber ein Buchungsprozess eines Bescheides unseres Moduls (in der Branche Wasserwirtschaft --> ein Bescheid beinhaltet mehrere Verkaufsrechnungen/Gutschriften) nicht zur selben Zeit die selben Tabellen weil mehrere Berechnungsteilschritte erledigt werden müssen, die unterschiedliche Tabellen lesend und schreibend bearbeiten. So können zumindest theoretisch mehrere Bescheide parallel verarbeitet werden. Sollten Satzsperren auftreten, wird das von der Massenverarbeitung auch erkannt und die Zeile wird später nochmal versucht zu bearbeiten. Nach ersten Performancetests mit unterschiedlichen Anzahl an parallelen Sitzungen hatte sich zuerst herauskristalisiert, das zwei parallele abarbeitungssitzungen schneller sind als eine, aber auch schneller als mehr Sitzungen, da dann zu viele Buchungen durch Satzsperren nochmal behandelt werden müssten. Der Unterschied zwischen 1 und 2 Sessions war zwar nicht so enorm, aber durchaus spürbar. Aber gut letztlich kann ich mich damit auch abfinden, dass wenn die Parallelität die Ursache sein sollte, das Feature wieder auszubauen.

Grüße René