nicht angemeldet
Problem des gegenseitigen Überschreibens durch mehrere NutzerInnen
Hallo,
mein derzeitiges Projekt verlangt, dass viele TeilnehmerInnen auf gewisse Datensätze zugreifen können und diese verändern können.
Ursprünglich wollte ich diese Datensätze ja in einfachen Text-Dateien (.txt) parken. Sobald jemand eine dieser Text-Dateien aufruft, so der Plan, würde der Inhalt via PHP in einem temporären Feld gespeichert, neue Inhalte diesem hinzugefügt, bzw. alte aktualisiert und die gesamte Textdatei mit dem aktualisierten Feld via Mode "w" überschrieben. (Mode "a" wie "c" erscheinen mir insofern nicht als zielführende Option, da aktualisierte Werte die alten ja überschreiben SOLLEN)
Soweit in der Theorie.
Nun stehe ich diesem Ansatz aber zunehmend skeptisch gegenüber...
...denn greifen beispielsweise zwei Personen zur selben Zeit auf eine der Text-Dateien zu, und überschreibt Person A die Textdatei mit ihrem aktualisierten Feld VOR Person B, so ÜBERSCHREIBT Person B wiederum die von Person A vorgenommenen Änderungen, selbst wenn es sich nicht um ein und denselben Datensatz in der Text-Datei handelt, da Person B den Inhalt der Textdatei ja noch VOR den Anpassungen durch Person A in ein temporäres Feld zur eigenen Bearbeitung übernommen hat.
Ist also für die von mir beschriebenen Zwecke der Einsatz einer Datenbank zwingend ratsam?
Ich bin darüber hinaus auch für weiterführende Tipps und Tricks bezüglich dieser oder auch ähnlich gelagerten Herausforderungen sehr dankbar!
Danke für jede wohlgemeinte Stellungnahme .
-
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
-
Tach,
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).
und das muss man dann auch noch so geschickt machen, dass man keine TOCTTOU-Fehler macht; ich würde das nicht vollständig selbst implementieren wollen.
mfg
Woodfighter