Replizierkonflikte

[Thunder]

Hallo Leute,
ich habe eine PersonalveränderungsDB entworfen und in den testlauf geschickt.Dh die Personalabteilung stellt eine Änderung ein (Beginn Arbeitsverhältnis, Ende AV, Namensänderung,..) - eine Mail wird an einen definierten Verteiler geschickt und die Abteilungen können Ihre ToDo-Liste in der DB abhaken.
Das Problem ist jetzt, das sich jetzt natürlich jede Menge Replizierkonflikte bilden, wenn mehrere User am gleichen Dokument rumbasteln. Wie kekomme ich das am saubersten gelöst ?

[Driri]

Hi,

vielleicht bringst schon was, die Option "Replizierkonflikte mischen" in der Maske zu aktivieren. Dadurch entstehen nur noch Replizierkonflikte, wenn die User das selbe Feld ändern.

Ansonsten, wenn die Anwendung bei euch nur an einem Standort auf dem Server genutzt wird, könnte man auch beim Öffnen eines Dokuments ein Sperrdokument anlegen, auf das immer geprüft wird. D.h. wenn ein Sperrdokument exisitiert, wird das Bearbeiten verweigert. Beim Schließen des Dokuments muß das Sperrdokument natürlich gelöscht werden.

Ist allerdings auch keine saubere Lösung, vor allem muß man dann einiges abfangen.

[Thunder]

Danke - ich denke das mit dem Mischen könnte für mich schon die Lösung sein, weil zwar mehrere Leute gleichzeitig am Dokument arbeiten, aber nicht am selben Feld.
Ich werde das mal austesten.

[koehlerbv]

Obicht, das Thema ist wirklich nicht trivial !
"Replizierkonflikte mischen" ist immer eine gute Idee, nützt aber nix, wenn es (gleichzeitige Arbeit auf einem Server) zu Speicherkonflikten kommt.
Ausserdem muss sichergestellt werden, dass es tatsächlich keine gemeinsam änderbaren Felder gibt. Beliebte Stolperfalle sind prinzipiell veränderte Felder wie "History" oder "LastModified" und sowas oder Statusfelder.
Dokumentsperren haben auch ihre Tücken - wehe, diese werden nicht zurückgesetzt, weil zum Beispiel jemand Notes nicht korrekt beendet oder beenden kann. Da muss dann also auch noch ein Aufräum-Agent her, und bis der sein Werk getan hat (relativ sicher geht das nur, wenn mit höchster Wahrscheinlichkeit niemand mehr mit der DB arbeitet - also nachts), kommt niemand mehr an das Dokument 'ran. Sperrdokumente wirken auch nur auf einem Server, nicht in verteilten Umgebungen. Ausserdem verursachen sie 'ne Menge Datenmüll (deletion stubs).

Irgendwie geht mir hier wieder ab, dass man sich erst Gedanken macht über die Problematik, nachdem das Kind bereits in den brunnen gefallen ist. Sowas hätte eigentlich schon geklärt werden müssen, bevor man mit dem prinzipiellen DB-Design überhaupt anfängt.

Natürlich gibt es auch weitere Möglichkeiten, um der Konflikt-Problematik aus dem Weg zu gehen. Änderungen an einem Dokument könnten beispielsweise in eine Mail-In-DB gesendet werden und dort nach Eingang verarbeitet (in das eigentliche Dokument übertragen) werden. Ist halt ein ganzes Stück aufwändiger.

Sind hingegen Replizier- und / oder Speicherkonflikte nicht auszuschliessen. jedoch recht selten, kann man auch Routinen schreiben, die automatisch oder mit entsprechender Benutzerführung die Auflösung der Konflikte unterstützen. Ich habe gerade für ein solches Szenario ein Toolset programmiert, das Konflikte ermittelt, die jeweils unterschiedlichen Items visualisiert und den Transfer von Items von Loosers zum Winner nach Auswahl per Knopfdruck ermöglicht.

Replizier- und Speicherkonflikte sind ein weites Feld und der Preis, den wir für die hervorragenden Möglichkeiten replikabler Notes-DBs bezahlen  

Bernhard