Probleme mit Sperren von Dokumenten im Cluster ($Writers und $WritersDate)

  • Moin,


    unser Entwickler hat in einer geclusterten Datenbank (Cluster mit 2 Membern auf Domino 10.0.1 FP2 deutsch mit Windows 2016) das Sperren von Dokumenten aktiviert. Die Anwender arbeiten auf beiden Servern.

    Die Clusterreplikation scheint auf dem ersten Blick zu funktionieren, da die Anzahl der Dokumente gleich ist und sich auch bei Änderungen innerhalb von Sekunden in beiden Datenbanken angleicht.


    Nun haben wir das Problem, dass das Entsperren von Dokumenten sporadisch nicht funktioniert. Die Dokumente bleiben dann nach dem Schließen gesperrt. Sie bleiben bei einem Server in einer dafür erstellten Ansicht stehen, in der Anwendung auf dem Clustermember sind sie aber verschwunden.


    Frage in die Runde: Sind Datenbanken, die diese Funktion haben überhaupt dazu geeignet, im Cluster zu laufen?

    Welche Möglichkeit habe ich als Admin, das korrekte Entsperren zu gewährleisten?


    Danke und Gruß

    Els

  • Ich habe das nur in wenigen Datenbanken aktiv und da, wo es mit hängen gebliebenen Locks Probleme gab hab ich nach und nach nächtliche Aufräumagenten eingerichtet. Nach 24h offenem Lock gibt's i.d.R. eine Warnung an den Nutzer (falls mal jemand absichtlich sein Notes offen stehen gelassen hat oder abgestürzt war und noch weitermachen möchte oder der Laptop mit offenem Dok in den Ruhezustand gefahren ist - alles schon gehabt) mit dem Hinweis bitte das Dokument wenigstens einmal auf- und wieder zuzumachen damit der Nutzer die Sperre selbst aufhebt. In der darauf folgenden Nacht, sofern der Nutzer nicht reagiert hat, wird die Sperre dann rigoros entfernt - auch wieder mit Info an den Nutzer und eine Log-DB. Seitdem ich das so laufen hab bekomme ich keine Hilferufe mehr aus den betreffenden Teams, davor gab es so 1-2 mal im Monat Probleme.


    Wenn ich mir die Art anschaue, wie die Locks gleichzeitig auf mehrere Server unter Umgehung der Replikation geschrieben werden wundert mich da gar nichts. Es erfüllt aber seinen Zweck und ist besser als gar nichts.


    Das viel größere Problem sind für mich in dem Zusammenhang die Kombination Softdeletion + Lock, da lassen sich die Sperren weder manuell noch gescripted aufheben, da kommt dann immer der Fehler, dass das Dokument ja gelöscht ist. Das Lock verhindert ein administratives Undelete. Hier kann nach meinen Tests nur der Sperrer (und Löscher) das Problem selber durch Undelete lösen, erst danach kann man wieder ganz normal die Sperre beseitigen. Das löse ich dann, indem ich in größeren Abständen in den betreffenden DB's am Wochenende oder in der Nacht entweder das Locking oder die Softdeletions kurz komplett abschalte und dann etwas später wieder frisch aktiviere. Alternativ habe ich in einigen Fällen begonnen einen anderen "Lösch"-Mechanismus einzubauen über ein Feld, das dann die betreffenden Dokumente ausblendet statt wirklich zu löschen und die tatsächliche Löschung macht dann wieder später ein Aufräumscript.

  • Das Problem Softdeletion + Lock durch einen dritten Nutzer hatte ich gerade gestern erst wieder, habe jetzt eine Lösung (bzw. Workaround) dafür gefunden.

    Statt die Sperre normal (über Bordmittel, also das Menü) aufzuheben, was bei gelöschten Dokumenten nicht funktioniert geht der Umweg über das Löschen der Steuerfelder, also @Setfield( "$Writers", @Unavailable ) usw.


    Nebeneffekt: die Softdeletion wird dadurch aufgehoben - da es aber jetzt keine Sperrung durch eine dritte Person mehr gibt kann man jetzt selbst auf normalem Weg löschen. Bingo. Man muss sich nur merken, welches Dokument es war und das in der DB anschließend auch wiederfinden.


    Übrigens: die Manipulation dieser Felder wird nicht im $UpdatedBy oder $Revisions dokumentiert, man sollte wissen, was man da tut! Nach dem Löschen ist das aber vermutlich irrelevant. Löschprotokoll wird in dem Zusammenhang sicher nochmal ein spannendes Thema ;)


    Carsten