Jörg Reinholz: Problem des gegenseitigen Überschreibens durch mehrere NutzerInnen

Beitrag lesen

Moin!

Ursprünglich wollte ich diese Datensätze ja in einfachen Text-Dateien (.txt) parken.

Ja. Das gemeinsame Arbeiten an Dateien ist definitiv eine Herausforderung. Und es kann keine EINE oder allgemeingültige Antwort geben.

Das Problem ist schon mal das "verbindungslose" http-Protokoll.

Am einfachsten ist es, die Datei, sobald diese jemand bearbeiten will, zu locken und das lock an die Session zu binden (man lege eine für eine datei.txt eine datei.txt.lock an).

Wenn also jemand datei.txt öffnen will und es existiert die datei.txt.lock, dann reinschauen, die Session-id auslesen, prüfen ob das Session-File (noch) existiert und in dem Fall die Sperre melden ("Anderer Benutzer arbeitet gerade daran. Versuchen Sie es später wieder.")

  • Existiert die Session nicht mehr, dann eigenen lock mit der eigenen Session ID setzen und loslegen.
  • Gibt es datei.txt.lock nicht, dann diese mit der eigenen eigenen Session ID als Inhalt erzeugen und loslegen.
  • Beim Speichern prüfen, ob die datei.txt.lock existiert und den die eigene Session-id enthält (kann ja vom admin gelöscht worden sein, weil eine gesetzte Sperre nicht aufgehoben wurde (Verbindung weg, Blue-Screen, [ALT]+[F4] ...) aber jemand anderes weiter arbeiten sollte/musste/partout wollte...

Andere Konzepte laufen darauf hinaus, mit Tools wie diff die Änderungen anzuzeigen und den Benutzer zu fragen, welche er nun beibehalten wolle. Das kann ganz schön Aufwand machen.

Wäre noch etwas wie git, also eine Versionsverwaltung im Backend: Datei auschecken, Datei bearbeiten, Version einchecken...

Oder halt Datenbank. Aber auch hier gilt: Wer zu letzt speichert behält recht ...

Jörg Reinholz