AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
23.11.20 - 17:06:05
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Lotus Notes / Domino 10
| |-+  ND10: Entwicklung (Moderatoren: eknori, fritandr, koehlerbv, Tode)
| | |-+  Dokumentensperre (Bordmittel oder selber programmieren)
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: Dokumentensperre (Bordmittel oder selber programmieren)  (Gelesen 221 mal)
PromITheus
Junior Mitglied
**
Offline Offline

Beiträge: 97


« am: 16.11.20 - 11:32:37 »

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.
Gespeichert

Gruß Marcel
Tode
Moderator
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6509


Geht nicht, gibt's (fast) nicht... *g*


WWW
« Antworten #1 am: 16.11.20 - 11:47:34 »

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.
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
CarstenH
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 319



« Antworten #2 am: 16.11.20 - 12:43:29 »

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
Gespeichert
PromITheus
Junior Mitglied
**
Offline Offline

Beiträge: 97


« Antworten #3 am: 18.11.20 - 15:07:31 »

Danke für eure konstruktiven Beiträge. Es ist schön das hier mal die einfachere, die bessere Lösung ist  Grin
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)  Smiley
« Letzte Änderung: Heute um 15:30:00 von PromITheus » Gespeichert

Gruß Marcel
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: