Tach!

1. JSON vs serialize: Von mir aus auch gerne serialize/unserialize. Problem bleibt. Allerdings ist mir JSON lieber, denn JSON ist ein standardisiertes Format, praktisch alles und jeder kann damit umgehen. Mit PHP serialize habe ich das nicht.

Wozu brauchst du die Standardisierung? Soll es ein Projekt werden, bei dem man von mehreren Plattformen aus auf die Daten zugreifen muss? Wenn du derzeit nur PHP verwendest und erstmal nichts weiter planst, wäre eine Standardisierung nur YAGNI.

Warum eine Klasse? file_get_contents() und file_put_contents() erledigt den Zugriff in einem Rutsch. Für das Schreiben kennt file_put_contents() auch ein Flag, das die Sperre setzt.

1. Eine Klasse weil ich OOP programmiere. Eine Datei ist ein Objekt => eine Klasse. Die hat Methoden wie size() oder isWritable().

Und das brauchst du alles für die simple Aufgabe der Konfigurationsdatenspeicherung? Oder willst du nur einfach aus Spaß an der Freude und der Vollständigkeit halber - auch wenn es derzeit nicht benötigt wird - eine Full-Blown-Dateiverwaltungsklasse schreiben?

Mit file_***_contents habe ich folgendes Problem: [TOCTTOU]

Das stimmt natürlich. Deswegen ja auch lieber SQLite.

dedlfix.

hi,

Das tue ich bereits. Meine Frage war, ob das so OK ist.

Klar. Mit einem LOCK_EX über den gesamten Prozess bist Du auf der sicheren Seite!

Denn es kann durchaus sein, dass ein Aufruf des Programms die Daten nicht ändert, sondern nur ausliest. Dann bräuchte ich ja nur LOCK_SH.

Das wäre dann die Optimierung, da musst Du selber ins Detail gehen und genau hingucken. Es kommt auf den konkreten Anwendungsfall an. Wenn Deine Klasse/Interface die Bezeichnung 'abstrakt' (bitte nicht verwechseln mit 'abstrakter Klasse') nicht verlieren soll, wirst Du ein 'LOCK_EX' nicht im Programmcode notieren.

Vorschlag:

  
// im Programm  
$db = new Datenbunker;               // nur lesende Zugriffe  
$db = new Datenbunker ('lock' => 1); // RW atomar  

Hotti

Tach!

Einziges Problem ist, dass dann das komplette Programm auf "von vorn beginnen" eingerichtet werden muss. Denn mit den eingelesenen Daten geschieht ja etwas, sie werden im ganzen Programm verteilt.

Vermutlich nicht komplett. Ich weiß nicht, was genau du mit den Daten anstellst, aber meist ist es doch nur ein Lesen für einen einzigen Request mit anschließendem Verwerfen neben allen anderen Daten am Requestende. Und wieder nur ein Lesen für den nächsten Request, usw. Ändern kommt üblicherweise nur recht selten vor. Das "von vorn beginnen" beschränkt sich also auf den Fall, das jemand was ändern will.

Webbasierte Bearbeitung findet ja in mehreren Prozessen statt. [...] 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.
Dieses Problem ist mir durchaus bewusst. Es liegt allerdings mMn. auf einem höheren Abstraktionslayer.

Ja, aber diesen Fall musst du am Ende auch noch lösen, zusätzlich zu den Parallelitätsproblemen beim eigentlichen Datei-Schreibvorgang.

Beginnt ein Benutzer eine Datei zu editieren, wird ihm der Zeitstempel des letzten Edits mitgegeben. Wenn er speichert, wird anhand des Zeitstempels (oder einer Versionsnummer, etc.) überprüft, ob die Datei inzwischen noch einmal geändert wurde. Wenn ja, bekommt der Benutzer eine Fehlermeldung und den Hinweis, er solle doch bitte seine Änderungen an die neue Version der Datei anpassen.
Dieser Mechanismus erfordert allerdings die Lösung des von mir angesprochenen Problems mit Dateisperren, oder?

Nur für den eigentlichen Schreibvorgang. Du musst ja selbst für die Zeitstempelprüfung (und dem potentiellen nachfolgenden Schreiben) nach dem Formularabsenden sicherstellen, dass nicht innerhalb deines Prozesses ein anderer Prozess querschießt.

Datenbankbasiert könnte man ein UPDATE ..., timestamp=NOW() WHERE id=$id AND timestamp=$old_timestamp loslassen. Wurde dann ein Datensatz geändert, war alles bestens und man ist schon fertig. Nur bei 0 affected rows gab es ein Problem mit zwischenzeitlicher Fremdbearbeitung. UPDATE ist ein atomarer Prozess, dafür sorgt das DBMS, da muss man sich nicht noch um weitere Sperren kümmern, die zwischen Lesen zwecks Ermitteln des aktuellen Timestamps für die Prüfung und Schreiben eine Parallelbearbeitung verhindern. Letzteres musst du aber bei dateibasiertem System mit Dateisperren selbst implementieren. Damit hast du dann zwei Abbruchbedingungen: einmal der geänderte Timestamp und dann das Misslingen des Schreibens, weil der EX nicht nahtlos nach dem SH zu bekommen war.

dedlfix.

Hello,

Dieses Problem ist mir durchaus bewusst. Es liegt allerdings mMn. auf einem höheren Abstraktionslayer. Beginnt ein Benutzer eine Datei zu editieren, wird ihm der Zeitstempel des letzten Edits mitgegeben. Wenn er speichert, wird anhand des Zeitstempels (oder einer Versionsnummer, etc.) überprüft, ob die Datei inzwischen noch einmal geändert wurde. Wenn ja, bekommt der Benutzer eine Fehlermeldung und den Hinweis, er solle doch bitte seine Änderungen an die neue Version der Datei anpassen.

Ich habe dazu mal ein Beispiel verbrochen, das immer noch im Netz steht. Da wid der Vereinfachung halber aber die ganze Datei abgefragt auf Änderung und nicht der diskrete Datensatz. Für den wahren Betrieb müsste man die Conflict-Counter auf Satzebene odre sogar bis auf Feldebene hinunter tragen. Eine Datenbank (Client-Server), die das auf Satzebene schon 1993 so gemacht hat, ist bTrieve (Später Pervasive Computing).

Ich habe das Beispiel allerdings mit Filefunktionen aufgebaut. Guckst Du hier und spielst vielleicht auch mal im konkurrierenden Betrieb:

http://selfhtml.bitworks.de/artikel_locking/adressen.php
http://selfhtml.bitworks.de/artikel_locking/adressen.php.txt

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg