Domino 9 und frühere Versionen > ND8: Entwicklung

Speicherkonflikt tritt immer wieder auf

<< < (4/5) > >>

Peter Klett:
Schreib doch mal, wie ich den Konflikt reproduzieren kann, dann setze ich mich morgen da mal ran

koehlerbv:
Diese vier Zeilen erzeugen nie und nimmer einen Speicherkonflikt. Da muss noch ein weiterer Prozess laufen.

Wenn Du - wie Peter schon schrieb - eine Version hinbekommst, mit dem wir das nachvollziehen können, dann ist auch der Fehler schnell gefunden. Aber eigentlich müsstest Du das auch selbst mit dem Debugger hinbekommen.

Bernhard

Christian Kröll:
Ich versuche Euch morgen eine DB zu posten, mit der Ihr den Effekt nachvollziehen könnt - sitze gerade dran.
Falls nicht: Das Oktoberfest kommt ja irgendwann  ;)

Christian Kröll:
wie eigentlich schon vor dem Post meines Problems geprüft, am Code liegt es nicht:
Das Setzen der Werte ist richtig und das QuerySave Event war keine Beauty (Danke für das deutliche Draufstossen, Bernhard), läuft aber auch wie gewünscht. Im Debugger waren nie weitere Prozesse zu sehen.

Beim vergeblichen Versuch, Euch lokal eine Db zu erstellen, die auch den Konflikt bringt, kam mir der Gedanke, dass doch vielleicht im Cluster ein Bug sein könnte. Wie Bernhard sagte, alles Stop und auf Anfang (allerdings im QuerySave...)
Agenten und Programme laufen dort keine, also nochmals zum IBM-Support. Dortbin ich bei auf APAR LO52374 gestossen (https://www-304.ibm.com/support/docview.wss?uid=swg1LO52374 bzw. https://www-304.ibm.com/support/docview.wss?uid=swg21444933).

Zusammenfassung:
Mehrfach gespeicherte Dokumente in einer geclusterten Anwendung sind mit der Maskeneigenschaft "Konflikte erstellen" erstellt worden, also kein $ConflictActions-Feld. Später wurde die Eigenschaft auf "Mischen/Keine Konflikte" geändert. Wenn nun das Dokument erneut gespeichert wird, dann wird das Feld $ConflictAction="3" erstellt. Das führt dann aber zu einem Replikationskonflikt im Cluster.

Lösung ist simpel: Replikation stoppen, Design auf beiden Repliken ändern und das Feld $ConflictActions ersetllen/auf "3" ändern, Replikation starten.

Hier in meinem Fall: Das Stammblatt, dass hier zum Konflikt führt, wird beim Speichern eines anderen Dokuments im Hintergrund erstellt und mit Daten gefüllt. Auch spätere Änderungen laufen im Hintergrund in das Stammblatt. Erst wenn die Mitarbeiter direkt mit dem Stammblatt arbeiten und speichern, wird das $ConflictAction erstellt. Dann macht's natürlich "Puff".
Das sieht dann leider so aus, als hätte man einen Speicher- und keinen Replikationskonflikt.


Diesen Thread können wir bitte schließen. Bernhard und Peter - Euch vielen Dank!

koehlerbv:
Faszinierend - da muss man erstmal drauf kommen! Respekt!

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete