Seitenreload

[Rolf B]

Hallo pl,

stimmt schon, ein Auto-Update müsste die vom User aktuell editierte Zelle gesondert behandeln. Die Frage ist nur, wie? Weil: Wenn ich beim Editieren überholt worden bin, dann ist mein aktueller Edit ohnehin problematisch, weil er auf falschen Grundlagen basiert. Resolve-Strategien für Edit-Kollisionen gibt's reichlich, und ob ein optimistisches Sperrverfahren hier sinnvoll ist, hängt von der konkreten Fachlichkeit ab. Sprich: wie hoch ist die Wahrscheinlichkeit, dass zwei User die gleiche Zelle editieren? Ist sie gering, dann kann man einfach Editieren lassen und demjenigen, der als zweites Speichert, ein "Ätsch" melden. Der Background-Update kann diese konkurrierende Änderung ebenfalls feststellen und dem User mitteilen: Deine Bearbeitung ist obsolet [OK] - und nach Klick auf OK isse dann weg.

Die aufwändigste Lösung ist dann, dem überholten User beim SPEICHERN anzuzeigen, dass er überholt wurde und wie die neuen Daten aussehen. In einem Merge-Dialog kann man dann die Daten des Überholers sehen und die eigenen Daten, und dann den konsolidierten Stand eingeben (so wie man es beim Checkin in GIT oder anderen Sourcecontrol-Systemen tut). Je nach Art der Daten kann der Server ggf. sogar automatisch mergen. Das ist je nach Daten alles andere als trivial. Ob diese Lösung sinnvoll ist, hängt wieder von der jeweiligen Fachlichkeit ab.

Ist das nicht machbar oder tolerierbar, dann kommt noch eine pessimistische Sperrstrategie in Betracht. Aber nicht auf Tabellen-Ebene, sondern auf Zellen-Ebene, d.h. sobald der User mit dem Editieren einer Zelle beginnt, gibt's einen Ajax-Request an den Server, der ihm die Zelle reserviert. Und der Edit-Mode geht erst an, wenn dieser Request mit "Erfolg" beantwortet wird.

Nun hat man aber ein anderes Problem: Was macht man mit vergessenen Locks? Z.B. weil ein User zu Editieren begonnen hat und dann irgend ein Spectre ihm einen BSOD beschert hat. D.h. wenn ich EDIT drücke und ein älterer Lock da ist (was „älter“ ist, hängt von der typischen Edit-Dauer ab), muss ich die Möglichkeit haben, diesen Lock zu übergehen. Und wenn ich der User bin, dessen Lock da gerade geknackt wurde, muss ich natürlich im Rahmen des ohnehin stattfindenden Background-Update (oder spätestens beim Speichern) ein Signal erhalten, dass mein Edit leider für den Popo war und ich jetzt in die Tischkante beißen darf (oder in den Finger von User XYZ, der meinen Lock gemopst hat).

Ohne JavaScript ist das aber alles nicht machbar, in dem Fall hilft nur eine eigene Edit-Seite, die nach "Speichern" zur Tabelle zurückkehrt.

Rolf