Paralleles Anlegen von Zeitungsvorgängen führt zu Verknüpfungen mit falschen Überordnungen

[andre-hohmann]

In der SLUB Dresden wurden beim Anlegen von Zeitungsvorgängen die Ausgaben-Vorgänge mit den Vorgängen anderer Überordnungen verknüpft. Ursache ist, dass die Vorgänge für unterschiedliche Zeitungen von zwei Kolleginnen gleichzeitig oder in einem knappen Zeitfenster angelegt haben:

• Kollegin 1 legt die Ausgaben-Vorgänge für Zeitung X an - die Ausgaben-Vorgänge werden jedoch mit dem übergeordneten Vorgang der Zeitung Y (Kollegin 2) verknüpft.
  Entsprechend wird auch der Vorgangstitel der Ausgaben- und Jahr-Vorgänge mit der PPN der falschen Überordnung gebildet.
• Kollegin 2 legt die Ausgaben-Vorgänge von Zeitung Y an - die Ausgaben-Vorgänge werden jedoch mit dem übergeordneten Vorgang der Zeitung X (Kollegin 1) verknüpft.
  Entsprechend wird auch der Vorgangstitel der Ausgaben- und Jahr-Vorgänge mit der PPN der falschen Überordnung gebildet.

Beiden Kolleginnen wurden zunächst Dubletten-Warnungen angezeigt, obwohl für deren Zeitungstitel die Vorgänge noch nicht vorhanden waren. Vermutlich, weil für die jeweils andere Zeitung Ausgaben an den jeweiligen Tagen vorhanden waren
Nach Prüfung der vermeintlichen Dubletten wurden die Ausgaben erneut im Kalender definiert und Vorgänge angelegt. Dabei wurden die Vorgänge jeweils mit dem falschen Titel verknüpft. Zudem wurden jetzt tatsächlich Dubletten erstellt (Siehe Screenshot unten).

Die dubletten Vorgängen wurden gelöscht, was recht zeitintensiv ist:

• Performance problem: Deleting of processes #4782

Vermutlich ist die Wahrscheinlichkeit gering, dass dieses Verhalten erneut auftreten wird, dennoch entstehen Aufwände und Irritationen, wenn es auftritt. Diese sollten vermieden werden. Um das Verhalten zu vermeiden wird in der SLUB Dresden derzeit darauf geachtet, dass Zeitungsvorgänge nicht von mehreren Personen im gleichen Zeitfenster angelegt werden.

Die exakte Nachstellung ist aufwändig und derzeit nicht möglich, so dass eine präzise Beschreibung in einem Bug-Issue ebenfalls nicht möglich nicht.
Deshalb (und weil eine Beschreibung auf Englisch schwer ist) würde ich gerne auf das Verhalten aufmerksam machen und in dieser Diskussion mögliche Ursachen erfragen. @henning-gerhardt meinte, dass dies daran liegen könnte, dass das Anlegen der Zeitungen anwendungsspezifisch statt benutzerspezifisch erfolgt. Dadurch wird die Vermengung der Vorgänge der Zeitungsvorgänge ermöglicht.
Im besten Fall können die Ursachen des Verhaltens in dieser Diskussion ermittelt werden und ein Issue mit spezifischen Zielen erstellt werden.

Dubletten der Zeitungsausgaben

[apiller]

Wir hatten das Verhalten in Halle auch. Wir haben uns via Chat abgesprochen, wer wann Vorgänge anlegt. Das Verhalten tritt auf sobald der Kalender in Benutzung ist. Interessanterweise werden die Ausgaben auch verkehrt angehängt, wenn keine Rechte auf die andere Zeitung (anderes Projekt) vorliegen. Das Verhalten ist bei uns öfter aufgetreten.

[andre-hohmann]

Interessanterweise werden die Ausgaben auch verkehrt angehängt, wenn keine Rechte auf die andere Zeitung (anderes Projekt) vorliegen.

Das kann ich durch unseren Fall bestätigen.

[henning-gerhardt]

Ggf. liegt es an der Klasse CalendarForm, da diese für die Kalender-Darstellung meines Wissens nach genutzt wird. Diese ist über eine Annotation als ViewScoped definiert statt des vermutlich besseren SessionScoped.
Ich kenne mich aber nicht so sehr in den UI Umsetzungen aus als das meine Vermutung zu 100% richtig ist. Aber vielleicht hilft dies bei der Fehlersuche.

[solth]

@ViewScoped ist die korrekte Annotation für CalendarForm (und prinzipiell die meisten anderen Seiten) und definitiv eine bessere Wahl als @SessionScoped. @SessionScoped Beans werden nur einmal pro User-Session instantiiert. D.h. wenn diese als Grundlage für eine Seite dienen und der Nutzer die gleiche Seite in zwei Tabs öffnet, überschreiben die Daten des zweiten Datensatzes die Informationen des ersten und es kommt zu unerwartetem Verhalten im ersten Tab. Dies kann bei @ViewScoped Beans nicht passieren. Diese sind einzelnen Tabs bzw. Browser-Instanzen zugeordnet und "leben" nur solange, wie das jeweilige Browser-Fenster oder Tab des Users geöffnet ist. Da @ViewScoped erst mit JSF 2 eingeführt wurde, haben wir noch viele Altlasten aus Kitodo 2-Zeiten, das JSF 1 nutzte und bei denen Form-Klassen fälschlicherweise im nicht dafür gedachten SessionScope liegen.

Mein spontaner Verdacht war auch, dass hier irgendwo der falsche Scope für eine Bean gewählt worden ist. Das von @andre-hohmann beschriebene Problem passt eher zu @ApplicationScoped Beans, die im Kalendar-Umfeld jedoch nicht zum Einsatz kommen. Solche @ApplicationScoped Beans werden beim Deployment der Anwendung instantiiert und leben bis diese wieder heruntergefahren wird. Alle Nutzer und alle Sessions teilen sich die eine, auf diese Weise instantiierte @ApplicationScoped Bean und damit auch die darin enthaltenen Daten. Im Kitodo.Production-Kontext kommen @ApplicationScoped Beans aber derzeit nur sehr begrenzt zum Einsatz, z.B. Beispiel bei der Indexierungsseite (weil der Status der Indexierung für alle User zu jedem Zeitpunkt gleich ist) und für die Sperrung von Vorgängen im Metadaten-Editor (weil dies eine globale Information ist, die sich alle User teilen).

Da dieser Scope bei der CalendarForm jedoch nicht verwendet wird, gehe ich stattdessen davon aus, dass die dazugehörige Service-Klasse Daten speichert, die Aufgrund ihrer "Singleton"-Natur auf ähnliche Art von allen Nutzern geteilt werden, wie es bei @ApplicationScoped Beans der Fall ist. Vielleicht sollte man daher den CalendarService diesbezüglich einmal näher untersuchen.

[andre-hohmann]

Ich frage mich, ob eine Behebung aufwändig wäre.
Sich darüber abzustimmen, dass nicht zwei Personen Zeitungsvorgänge anlegen, ist auch in unserem Fall gut möglich ohne die Abläufe zu stören. Mir wäre jedoch wohler dabei, wenn die Ursache behoben werden könnte.