Dokumentensperre (Bordmittel oder selber programmieren)

[PromITheus]

Guten Morgen,

bevor einige rufen "Aber da gibt es doch schon Forumseinträge!" bitte kurz weiterlesen :-) Die Einträge sind meist viele Jahre alt und nicht für die aktuelleren Versionen.

Wir haben eine App bei der nun doch mehrere Personen ein Dokument öffnen bzw. bearbeiten. Die Nutzung der App (Benutzer und Dokumentenanzahl) wird vermutlich die nächsten Monate stark wachsen. Ich möchte nichts integrieren, was sich mit der Zeit als nicht brauchbar herausstellt. Wir haben bisher keinen Cluster.

Möglichkeit A:
In den Datenbankeigenschaften Seite 1 "Sperren von Dokumenten zulassen" aktivieren.
Möglichkeit B:
Selber einen Leseschutz programmieren.

Wie ist da der aktuelle Stand, eure Erfahrungen! Taugt die integrierte Dokumentensperre (A) mittlerweile? Oder besser selber programmieren? Oder holt man sich mit (B) nur neue Probleme ins Haus?

Danke schon mal für eure Einschätzungen.

[Tode]

ALSO: Der Stand ist der selbe wir der von den alten Forumsbeiträgen: Meiner Erfahrung nach hat sich an der Domino- eigenen Sperrfunktion seit Einführung quasi nichts verändert.
PRINZIPIELL funktioniert die, es kommt nur -nach wie vor- vor, dass Dokumente nicht entsperrt werden, obwohl nicht mehr in Bearbeitung. Da hilft dann eine Ansicht mit allen gesperrten Dokumenten und ein "Admin- entsperr- Knopf" und / oder ein nächtlicher Entsperr- Agent.

Das ist auf jeden Fall einfacher, als das Ganze selbst zu schreiben. Auch das habe ich schon gemacht (also das ganze selbst geschrieben), aber da gibt es wirklich einige Hürden zu umgehen, und prinzipiell einiges an Code zu schreiben...
Meine eigene Implementation kam damals mit ca. 1.500 Zeilen Code verteilt über 3 Klassen aus, allerdings habe ich einige unserer "Standardbibliotheken" verwendet, die viele Aufgaben (wie Dokumentenlookups, Array- und Listenmanipulationen, etc.) schon mitbringen und
die in diesen Linecount nicht mit reinzählen.

[CarstenH]

Moin,

ich schließe mich Torstens Meinung an. Ich verwende den integrierten Sperrmechanismus ebenfalls in mehreren Anwendungen in Kombination mit nächtlichen Aufräumagenten und das sogar im Cluster. Selbst basteln (habe ich wie Torsten auch schon gemacht zu Zeiten bevor es den offiziellen Mechanismus gab) ist viel Aufwand für nichts, die Kompromisse die man dabei eingeht kann man sich mit deutlich weniger Aufwand mit der Standard-Sperre sparen.

Ursache für sporadisch übrig bleibende Sperren (und damit für den Aufräumagenten) sind entweder Crashs (selten) oder z.B. PC's die nach Inaktivität in den Energiesparmodus gegangen sind und den MA schlicht egal war dass sie da noch was offen hatten. Einige MA habe ich dabei beobachtet wie sie selbst bereits offene Dokumente doppelt und dreifach öffnen - wenn man selbst die Sperre hält bekommt man keine Warnung - und wenn dann die offenen Fenster in anderer Reihenfolge wieder geschlossen werden kommt es hin und wieder zu übrig gebliebenen Sperrflags.

Ein Sperrmechanismus (egal welcher Art) verleitet allerdings dazu, dass sich Nutzer in falscher Sicherheit wiegen. Leicht rekonstruierbares Beispiel:

A öffnet Dokument 1 - klickt auf Bearbeiten (und sperrt für sich im Hintergrund).
B öffnet Dokument 1 - Klickt auf Bearbeiten und bekommt Meldung dass A gerade bearbeitet (B bleibt im Lesemodus und bittet A rauszugehen).
A schließt Dokument 1 (und speichert seine Änderungen) [und teilt B mit, dass er jetzt bearbeiten darf].
B hat das Dokument 1 ja noch offen - klickt erneut auf Bearbeiten (und sperrt für sich im Hintergrund) und hat jetzt den Stand VOR der Änderung von A.
B schließt Dokument 1 und möchte seine Änderungen speichern, jetzt kommt der Hinweis, dass in der Zwischenzeit jemand anders das Dokument bearbeitet hat - je nach Antwort hat man anschließend einen "unerklärlichen" Replizierkonflikt (ist natürlich nicht unerklärlich) oder B kann nicht speichern.

Ich habe das Problem der mehrfach durch den selben Nutzer geöffneten Dokumente so umgangen, dass ich in den betreffenden Anwendungen, in denen das wichtig ist, die Bearbeiten-System-Aktion in den Views ersetzt habe und das Dokument immer zuerst im Lesemodus öffne (damit springt Notes auf den eventuell schon offenen Tab) und dann erst in den Bearbeitenmodus wechsle. Das andere, oben angesprochene Problem der bereits offenen Dokumente, ist eigentlich kein echtes Problem, da ja eine Konfliktwarnung beim Speichern kommt.

Den Nutzern sollte bei der Einführung gezeigt werden wie sie auf Konfliktwarnungen und Sperrmeldungen richtig reagieren. Seitdem habe ich so gut wie Null Probleme.

HTH
Carsten

[PromITheus]

Danke für eure konstruktiven Beiträge. Es ist schön das hier mal die einfachere, die bessere Lösung ist  
Die von euch beschriebenen Probleme haben ja etwas mit Fehlbedienung oder Abstürzen zu tun und würden so auch bei einer selbst erstellten Sperrklasse auftreten.

Meine Umsetzung:
Ich habe jetzt die Bordmittel Sperrfunktion aktiviert.
Eine spezielle Admin Sperr-Ansicht die alle Docs mit $Writers-Feld anzeigt erstellt und dort noch die Spalte $WritersDate eingefügt.
Die Admin-Aktion "Sperre löschen" löscht bei Bedarf einfach beide Felder.
Im Scriptcode der Dokumente frage ich ab, ob notesdocument.LockHolders(0) leer ist oder dem aktuellen Benutzer entspricht, um angepassten Code bei Sperre zu starten.
In einer Script-Löschfunktion musste ich vor dem Löschen ein notesdocument.Lock einfügen, damit die Löschung durchläuft.

Und eine Gute Nachricht habe ich auch. Carsten, die Sperrfunktion wurde anscheinend verbessert. Ich habe den von dir geschilderten Fall nachgestellt und bekam vom System folgende Meldung "Dokument wurde seit dem Öffnen verändert. Öffnen Sie es im Bearbeitungsmodus von der Ansicht aus neu." (siehe Bild)  

[ARM9]

Zu diesem Thema habe ich die Frage zu X-Page.
gibt es eine Möglichkeit Dokumente in X-Page zu sperren. Zur Zeit mache ich es mit einer Variable als Liste in der Datenbank. Wer welches Dokument geöffnet hat. Der Nachteil, wenn der User den Return Button im Browser benutzt, geht es nicht. Kann das JSF bzw Donimo selbst händeln?

[PromITheus]

Zu den X-Pages kann ich leider nichts sagen.

Ich habe noch eine Ergänzung aus der Praxis zu eingebauten Sperrfunktion:
Wie die anderen schon beschrieben haben, kommt es hin und wieder zu Dokumenten die nicht freigegeben wurden. Um den Pflegeaufwand gering zu halten, habe ich einen regelmäßigen Wartungsagent (Maintenance) eingerichtet.
Er prüft das Datum im Feld $WritersDate. Ist das schon ein paar Tage her, kann es sich nur um einen Fehler handeln. Diese Dokumente werden automatisch entsperrt.
Verhindert keine Supportfälle, sollte diese aber gerade bei stark genutzten Apps reduzieren.