nicht angemeldet
Tach!
Ich nochmal, und etwas genauer aufs Problem geschaut.
Einige Ideen die ich hatte:
* Erstmal mit LOCK_SH sperren, erst auf LOCK_EX wechseln wenn wirklich ein Schreibzugriff kommt. Das Problem dabei: Angenommen ich lese Informationen ein (es wird erstmal LOCK_SH geholt) und schreibe sie dann verändert wieder zurück (erst dann mit LOCK_EX). Was passieren kann:
- Programm A liest ein
- Programm B liest ein (geht, weil Prgm. A nur LOCK_SH hält)
- Programm A versucht zurückzuschreiben mit LOCK_EX, muss aber auf B warten, da B LOCK_SH hält
- Programm B macht das gleiche => Deadlock.
Und das selbst, wenn A und B verschiedene Teile der Datei ändern wollen. Einige DBMS können datensatzbasiert sperren, da passiert sowas nicht. Das Problem muss doch aber schon gelöst sein, denn Dateisperren existieren ja nicht erst seit gestern. Nach meinen Überlegungen muss der Prozess, der von SH kommend ein EX anfordert, ein Timeout haben. Wenn dieses eintritt, muss die gesamte Aktion für gescheitert erklärt werden, inklusive dass die Daten, die vorher aus der Datei gelesen wurden, ungültig werden. Es muss dann von vorn begonnen werden.
Das Problem ist jedoch eigentlich noch weitreichender, selbst mit Datenbank. Webbasierte Bearbeitung findet ja in mehreren Prozessen statt. Aufgrund eines Requests von A liest ein Prozess die Daten, erzeugt eine Response mit dem Formular, und beendet sich (natürlich unter Verlust aller Sperren). Nun hat der Anwender A fertig und will die Daten schreiben, aber Anwender B war schneller, und wenn A im selben Bereich geändert hat, sind Bs Änderungen gefährdet. Dieses TOCTTOU-Problem zu lösen, geht mit Dateisperen allein nicht mehr. Da braucht es auch noch einen Zeitstempel oder ein ähnliches eindeutiges Merkmal (Checksum), um die Originalität der Daten vor dem Ändern zu prüfen.
dedlfix.