Das Notes Forum
Domino 9 und frühere Versionen => ND9: Entwicklung => Thema gestartet von: Bruce Willis am 16.03.18 - 17:18:46
-
Hallo,
wenn in einer DB die Option "Sperren von Dokumenten zulassen" aktiviert ist, kommt es ab und zu vor, dass ein Dokument gesperrt und nicht wieder automatisch entsperrt wird.
Hat schon mal jemand versucht, etwas ähnliches aber besseres zu programmieren?
Geht es bzw. wie?
Danke & Gruß
Leo
-
Ist das nicht eine Funktion von der Notebook Datenbank, wo eine solche Funktion gewünscht ist, bis diese von dem Nutzer wieder freigegeben wird.
Admins könnnen Dokumente in der Datenbank wieder freigeben.
MFG Michael
-
Ist das nicht eine Funktion von der Notebook Datenbank...
Ja, das ist es.
Nur hatte der Kollege koehlerbv hier irgendwo einmal geschrieben, dass er diese Datenbank-Eigenschaft grundsätzlich nicht empfehlen sondern die Funktionalität selbst programmieren würde.
Sagte aber leider nicht, wie er es dies gemacht hatte... :-:
-
In Domino wird soweit mir bekannt zwischen Soft- und Hard-Locking unterschieden.
Das Hard-Locking erfordert für die Datenbank Transaktionsprotokollierung und wird über eine Datenbankeigenschaft aktiviert.
Das Soft-Locking ist per Default dabei, funktioniert aber nur unregelmäßig. (Meldung 'Benutzer xy hat dieses Dokument bereits in Bearbeitung')
Dies führt in der Regel zu Replikationskonflikten bei Speicherung.
Es handelt sich hierbei um keine richtige Dokumentsperre aber um eine Verhinderung von Konflikten.
In unseren Anwendungen habe ich dazu den OnSubmit-Event der Masken angepasst um auf aktuellere Speicherungen des gleichen Dokuments zu prüfen.
In diesem Fall gibt es eine Warnung mit halbmanuell geführter Zusammenführung der Felder/Inhalte.
Im QueryModeChange-Event der Masken prüfe ich auf den Wechsel von Lesen zu Bearbeiten und prüfe dann ebenfalls auf aktuellere Speicherung des gleichen Dokuments durch wen anders. In dem Fall wird das Dokument neu geöffnet und hat dann die aktuelleren Inhalte.
-
...
In unseren Anwendungen habe ich dazu den OnSubmit-Event der Masken angepasst um auf aktuellere Speicherungen des gleichen Dokuments zu prüfen...
Im QueryModeChange-Event der Masken prüfe ich auf den Wechsel von Lesen zu Bearbeiten und prüfe dann ebenfalls auf aktuellere Speicherung des gleichen Dokuments durch wen anders. In dem Fall wird das Dokument neu geöffnet...
Vielen Dank, es sieht sehr interessant aus.
Könntest Du evtl. noch dazu schreiben, wie Du die beiden realisiert hast?
-
Lustig wird das Thema erst, wenn es auf mehreren Servern möglich sein soll.....
-
Lustig wird das Thema erst, wenn es auf mehreren Servern möglich sein soll.....
Ist es jetzt mt der Sperre-Eigenschaft der DB anders?
-
Moin,
wir benutzen beides: "Allow document locking" und eine selbstprogrammierte Dokumentensperre.
Z.B. kann man das so machen:
Es gibt eine Ansicht, mit Formel Form = "Lockdoc", sortiert nach Item LockUNID.
Funktion SetLock(NotesDocument doc) legt ein Dokument an mit Form = Lockdoc, LockUNID = doc.UniversalID, LockName = @UserName usw.
Funktion IsLocked(NotesDocument doc) prüft anhand der UNID, ob es ein Lockdoc gibt oder nicht.
Funktion RemoveLock(NotesDocument doc) entfernt das Lockdoc.
Beliebig erweiterbar :-)
Beste Grüße
Gutierrez
-
Hallo Gutierrez,
vielen Dank, es klingt sehr interessant!
Heißt das also, dass man für so eine Sperre unbedingt zusätzliche Dokumente anlegen muss?
Gruß
Leo
-
Für einen "nachbildung" einer solche funktionalität müssen die informationen irgendwo ausserhalb des Dokuments abgreifbar sein, und damit mussen zusätzliche dokumente erstellt werden.
Wenn der Umgebung keine cluster umgebung ist (aber auf mehrere Server läufen sollte), wäre ich sogar dafür ein Dokument immer auf einen bestimmte Server zu suchen, und nicht "nur" in den (Lokale) repliek. Es könnte ja sein das die Information noch nicht repliziert würde, und damit das dokument anderswo bereits gelockt wäre.
Dafür musste also sichergestellt werden das alle potentielle Anwender an diesen "LockServer" dran kommen, jederzeit.
Wenn der Lockserver nicht erreichbar ist, darf nicht gelockt werden, sonnst kann auch hier das dazu führen das doppelte Änderungen passieren.
-
@Bruce Willis
Wenn du die Sperrinformation in das Dokument schreibst, das du gerade bearbeiten möchtest, musst du es ja einmal speichern, damit ein anderer, der das Dokument von Disk liest, die Info ja auch hat. Genauso beim "Entsperren". Evlt. kannst du die Sperrinfo ja über nen Agenten (RunOnServer) auf dem Server in Textdateien speichern und abrufen - wobei ich diese Idee verwerflich finde ;) Oder du legst ein Dokument an, wo du alle Sperrinfomationen sammelst, in einem Array. Das Problem hierbei ist, dass dieses eine Dokument ebenfalls kurzzeitig gesperrt sein müsste, weil jemand sein Sperrinformation hineinschreiben/löschen möchte. Kurzum: Versuch's mal so wie beschrieben. Ist nicht schwierig und ich glaube, es gibt im Internet auch eine Beispieldatenbank.
Beste Grüße
Gutierrez
-
@Bruce Willis
Wenn du die Sperrinformation in das Dokument schreibst, das du gerade bearbeiten möchtest, musst du es ja einmal speichern, damit ein anderer, der das Dokument von Disk liest, die Info ja auch hat. Genauso beim "Entsperren".
Und genau das ist der Grund warum selbstgebaute Sperrmechanismen nicht zuverlässig funktionieren können.
Dokument Lesen, Flag setzen, Dokument schreiben muss als atomare Operation ausgeführt werden ohne dass
andere Prozesse gleichzeitig zugreifen können. Das ist aber mit Bordmitteln nicht machbar.
-
@Pyewacket
Mir ist durchaus klar, dass ggf. zu race conditions kommen kann, aber in kleineren Umgebungen kann das imho vernachlässigt werden. Es funktioniert zu 99% :D
Beste Grüße
Gutierrez