Questions & Answers

[bIT_sosswald]

Hallo zusammen,

ist es möglich ein gelocktes Element (PageRef, bzw. PageRefFolder), welches von einem anderen User, in einer anderen Session bzw. einem Workflow gelockt ist per API aus einem Modul zwnagsweise zu "entlocken"?

Dabei wäre es auch akzeptabel wenn evtl. vorgenommene Änderungen verloren gehen.

Grund für die Frage ist, dass wir ein Modul haben welches programmatisch eine Ordner- und Seitenstruktur im Strukturbereich anlegt. Dabei kam es in der Vergangenheit zu Fehlern, da z.B. der Root-Knoten der programmatisch angelegten Struktur gelockt war.

ERROR 20.04.2015 14:31:15.414 (com.xxx.structureupdater.structure.CatalogCreator): Could not create structure.
de.espirit.firstspirit.access.store.templatestore.WorkflowLockException: Element '9882722' is locked by workflow!
     at de.espirit.firstspirit.store.access.DefaultStoreElement._setLock(DefaultStoreElement.java:468)
     at de.espirit.firstspirit.store.access.DefaultStoreElement._setLock(DefaultStoreElement.java:463)
     at de.espirit.firstspirit.store.access.DefaultStoreElement.setLock(DefaultStoreElement.java:440)
     at de.espirit.firstspirit.store.access.DefaultStoreElement.setLock(DefaultStoreElement.java:431)
     at com.xxx.structureupdater.structure.CatalogCreator.createCatalog(CatalogCreator.java:78)

Eine Alternative wäre aus Meiner Sicht die Bearbeitungsrechte des Teilbaums der Struktur so einzuschränken, dass kein User bzw. Workflow diesen Teilbaum bearbeiten darf.

Ideen wie man solche Fehler zukünftig vermeiden kann bzw. wie man Locks zwangweise entfernen kann, sind herzlich willkommen.

Grüße

Sandro

[MichaelaReydt]

Hallo Sandro,

ich befürchte, dass es nicht möglich ist, die Session eines anderen Users zu beenden.

Eine Vermeidung des Errors ist in meinen Augen nur durch eine vorherige Abfrage, ob das Root-Element bereits gelockt ist, möglich. In dem Fall würde ich als User dann jedoch einen Hinweis und einen Abbruch der Strukturanlegen erwarten. Ist die Frage, ob dies dann gewünscht ist.

Viele Grüße

Michaela

[mbergmann · Accepted solution]

Hallo Sandro,

hier ist es wichtig zu unterscheiden ob es sich um einen Workflow-Lock handelt (entspricht der Einstellung "Schreibschutz" beim entsprechenden Status) oder um einen aktiven Bearbeitungsmodus.

Deine Meldung zeigt einen Workflow-Lock, der sich übrigens auch nicht durch ein Beenden einer Session entfernen lässt. Außerdem wirken Workflow-Locks immer rekursiv (sie sind allerdings nicht rekursiv gesetzt).

Einen Workflow-Lock kann man programmatisch entfernen, indem man sich das StoreElement holt, dann zuerst setWriteLock(false) aufruft und dann setLock(true,[true|false]) und ggf. save([true|false]), setLock(false,[true|false]).

Die Frage ist ob das im Fall von Workflow-Locks wirklich sinnvoll ist, denn der Schreibschutz hat gerade den Sinn, sicherzustellen dass während einer Prüfung (z.B. im Rahmen eines 4-Augen-Workflows) eben keine Änderungen am Objekt möglich sind. Sonst würde ein Prüfer ggf. einen "veralteten" Stand freigeben während in Wirklichkeit ein Redakteur kurz vorher (=nachdem der Prüfer die Seite aufgerufen hat aber bevor er die Freigabe erteilt) noch eine Änderung gemacht hat.

Einen Lock durch einen aktiven "fremden" (=andere Session, d.h. ggf. auch durch denselben Benutzer) Bearbeitungsmodus kann man lediglich über das Beenden der entsprechenden Session per ServerMonitor entfernen.

Dein Ansatz das über entsprechende Rechte zu lösen wäre hier eine Lösung.

Eine vorherige Prüfung ob ein Element gelockt ist, funktioniert übrigens nicht 100%ig, weil theoretisch ein User das Element genau zwischen der Prüfung und dem Locken sperren könnte. D.h. hier ist der Weg der Wahl, das entsprechende Element selber zu locken, die Exception zu fangen (muss man ja sowieso, da CheckedException) und dann z.B. eine Fehlermeldung wie "versuchen Sie es später nochmal" anzuzeigen - also einen "fail fast"-Ansatz zu fahren.

Viele Grüße

Michael

[bIT_sosswald]

Hallo MIchael,

vielen Dank für die ausführliche Antwort!

Wie du geschrieben hast, ist das programmatische Entfernen eines Locks (egal ob durch einen Workflow oder einen User gesetzt) ein nicht gangbarer Weg, da im Extremfal die Session eines gerade aktiven Users beendet werden müsste.

Da das Modul automatisiert und über einen Schedule-Auftrag läuft kann jedoch keine "Bitte Versuchen Sie es später noch einmal" Meldung angezeigt werden.

Wir werden vermutlich den Weg über die Änderung der Rechte des entsprechenden Strukturknotens gehen, da fachlich keine Änderungen von Redakteuren daran vorgenommen werden müssen. Sämtliche "Arbeiten" daran werden nämlich programmatisch vom Modul erledigt.

Danke nochmals für die Antworten und beste Grüße

Sandro