Database mit Document Locking hinterlässt locked documents

[maxritti]

Hallo zusammen,


ich habe hier eine Datenbank, bei welcher Document Locking aktiviert ist.
Grund ist, dass etwaige Dokumente zwar mehreren Benutzern zur bearbeitung weitergegeben werden können, aber es soll immer nur ein Benutzer ein Dokument bearbeiten können. Also nichts paralleles um Konflikte o.ä. zu vermeiden.
Die DB liegt auf einem Domino Cluster, wird nicht repliziert und einfach per Notes Client genutzt.
Nun kommt es immer öfter vor, dass Dokumente welche bearbeitet wurden den Status "Locked" (also $Writers und $WritersDate Felder) behalten, auch wenn die Benutzer das Dokument schliessen.
Teilweise habe ich eben Dokumente gesehen, die $WritersDate aus 2015 hatten. Und da ist bestimmt der Client schon geschlossen worden.

Hat jemand dafür eine Erklärung, wie das sein kann?
Stürzt da ggf der Notesclient ab und lässt die Felder drinnen?
Wobei davon hätten wir bestimmt was mitbekommen.

Ich bin da ein wenig ratlos.

Ach so. Dominoserver 9.0.1FP6 und Notes Clients ebenfalls 9.0.1FP6

[JayDee]

Wir haben in ausgewählten Datenbanken das Hardlocking ebenfalls aktiv. Meine Erfahrungen sind diese:

- es funktioniert passabel gut, aber nicht zu 100%. Ein crashender Client lässt z.B. auch eine Sperre zurück.
- Wird die Sperre durch den Edit-Modus gesetzt, wird sie automatisch aufgehoben, wenn der Edit-Modus wieder verlassen wird
- Wird die Sperre via Kontext-Menü gesetzt, dann muss sie über diesen Weg wieder zurückgenommen werden, sonst bleibt sie bestehen. Gerade dieser Umstand ist Usern mitunter schwer zu vermitteln.

[Driri]

Wir haben vor Jahren die Erfahrung mit einer Anwendung im Clusterbetrieb gemacht, daß es unabhängig von Clientabstürzen immer wieder zu nicht erklärbaren Dokumentsperren kam. Dieses Verhalten trat nicht auf, wenn man die Anwendung von einem Nicht-Cluster-Server aufgerufen hat. Wir haben das nur bis zu einem bestimmten Grad verfolgt, die Vermutung lag aber Nahe, daß es sich um ein Problem im Umfeld des Notes-Clusters handelt. Wir hatten damals noch einen Cluster mit 8.5er Servern laufen.

[Flachmann]

Ich kenne ebenfalls Probleme diesbzgl. Eine Cluster-Umgebung kann ja i.a. nicht einfach aufgelöst werden, schließlich hat der Cluster seinen Sinn.

Da solche Locks nur vom Lock-User bzw. einem ACL 'Manager' aufgehoben werden können, erstellten wir letztlich einen Agent, der die Locks nach einer gewissen Zeit wieder löscht. Von Hand ist das ja viel zu aufwändig. So ein Agent ist zwar nicht gerade elegant, tut aber seinen Zweck.

Leider hat IBM hier seit Jahren nichts verbessert.

[maxritti]

Wie gesagt, die DB liegt nur auf einem Dominoserver, der zwar Member von einem Cluster ist.
Aber die DB selber liegt nicht auf mehreren Servern.

Dann nehme ich das wohl mal so als "works as designed" hin.

Vielleicht werde ich dann mal einen Anwendungsserver bei uns an den Start bringen, der nicht im Cluster ist.
Damit sollten die Probleme dann ja aus der Welt sein.

Mit dem Agenten wäre es zwar eine kostengünstigere Variante, aber wie Du selber auch schreibst nicht wirklich schön. 

[Peter Klett]

Du willst tatsächlich einen separaten Server aufstellen, nur weil ein Agent "unschön" ist?

Die möglichen Problemfälle, die JayDee dargestellt hat, hast Du damit aber immer noch nicht gelöst, also baust Du dann einen Agenten auf Deinem neuen Server... 

[thkn777]

Auf lange Sicht ist die Lösung mit dem "Housekeeping" Agenten in meinen Augen die beste Variante. Es kann immer etwas schiefgehen (siehe Murphy) und dann hast Du jemanden, der für Ordnung sorgt.