Counter, lesen, zurücksetzen

[Tom]

Hello,

Könntest du ein paar Erklärungen nachschieben, was mit der "Nichtberücksichtigung des konkurrierenden Betriebes" gemeint ist?
Fehlen die lustigen "flock()s"? Würden die das Problem beheben?

Ja, die fehlen.

ich hatte das gerade irgendwo hier mal wieder näher beleuchtet.
Eddi (Berlin) hatte dazu auch schon etliche Postings abgegeben, da flock() nicht ohne Berücksichtigung des OS die Lösung ist. Da besteht wohl in der Implementation (ggf. auch des Filesystems, auf dem es nicht funktiomniert) ein Bug.

i.d.R. Sollte eine Programmiersprache, wenn sie sich denn direkt der API des OS bedient, keine Probleme bekommen. Das aber nur am Rande...

Wir fassen mal zusammen:

Die Counter-Daten werden ausschließlich und in genau einer Datei gespeichert.
Für das Auslesen und das Verändern des Counters werden immer dieselben Scripte verwendet.
Hierzu werden von unterschiedlichen Prozessen eigene Instanzen davon gebildet.
Diese Intanzen wissen ersteinmal nichts voneinander.
Die gemeinsamen Ressourcen dieser Instanzen sind

• die Datendatei des Counters
• die API des OS, die durch die Scripte angesprochen wird.

Um zu verhindern, dass eine Instanz des Counters gerade die Daten holt, um die anschließend zu verändern und wieder wegzuschreiben, während eine andere Instanz gerade schon die Löschung (Leerung) der Datei veranlasst hat, um die bereits veränderten Daten wegzuschreiben, bedient man sich einer gemeinsamen Funktion, die für eine Serialisierung und "Taktung" der Vorgänge sorgt.

Diese Funktion muss (zumindest in wichtigen Teilen) tief im OS (Filesystem) verankert sein und darf nicht umgangen werden. Es gibt hier z.Zt. zwei geläufige Methoden:

Das Mandatory Locking  (befehlendes Sperren, zwingendes Warten)
  Hierbei unterwerfen sich jegliche Dateifunktionen dem Mechanismus der Sperrfunktion und
  können diese nicht umgehen. Auch Programme, die bei ihrer Erstellung keine Rücksicht
  auf Locking genommen haben, können dadurch "abgefangen" werden, da der Sperrmechanismus
  auf Filesystem-Ebene stattfindet.

Das Advisory Locking (beratendes Sperren, freiwilliges Warten)
  Hierbei müssen Programme gestzte "Flags" oder "Semaphore" eigenständig beachten und
  entsprechend berücksichtigen. Wurde der erforderliche Mechanismus nicht beim Programmentwurf
  eingebaut, bekommt das Programm nichts von der Empfehlung mit und es geschehen schwere
  Fehler.

Beide Verfahren teilen sich in die

• Beantragung (und wiederfreigabe) der Sperre
• Berücksichtigung der Sperre

Das komplizierte beim Setzen von Sperren liegt in der Tatsache, dass das OS (Filesystem) mitgebekommen muss, ob der Prozess, dem die Sperre gehört, noch lebt. Wenn nämlich der Prozess
stirbt, ohne dass das OS dies merkt, könnten sich "vagabundiernde" Sperren ansammeln, die
schon lange nicht mehr gültig sind aber trotzdem noch sperren. Die beiden Verfahren funktionieren daher also nur bei verbindungsbezogener, zustandsgebundner Kommunikation.

Auf den beiden genannten Verfahren baut dann auf Applikationsschichtebene das "academic Locking"
auf. Es ist ein "Wissens-Locking" (daher der Name). Es dient der Implementation von Kontrollmechanismen in verbindungsloser, zustandsloser Kommunikation, also auch für Webanwendungen.

Man speichert hier im Datenstamm einen Merker, der die letzte Veränderung registriert. Auch auf dieser Schicht gibt es die Unterscheidung von advisory und mandatory academic locking. Wird der Locking-Mechanismus vom DBMS übernommen, ist es ein mandatory academic Locking, wird er von der API (also z.B. PHP) implementiert, ist es ein advisory academic locking, da andere Applikationen ja nichts davon wissen können.

Das ist nun nochmal ein Auszug aus meinem immer noch nicht fertigen Artikel zum Thema Locking.

Es gilt:

Sollen Daten verändert werden, muss das Lock mit EXCLUSIVE bereits vor dem Holen der Daten beantragt werden und unverzüglich verändert, zurückgeschrieben und wieder entsperrt werden.

Sollen Daten lediglich in gültiger Form [1] angezeigt werden, reicht ein SHARED Lock, dass
aber ebenfalls sofort nach dem Holen der Daten wieder gelöst werden muss.

[1] Man kann Daten auch ohne jedes Lock auslesen, läuft dabei aber dann Gefahr, dass diese verstümmelt oder sonstwie ungültig sein können, da ein andere Prozess sich gerade mitten in
der Veränderungsphase befindet. Dieser Fehler ist natürlich nur bei advisory Locking möglich.
Bei mandatory locking könnte man während des eigentlichen Veränderungsvorganges [2] nicht lesen.

[2] Ein Veränderungsvorgang (Datenmanipulation) besteht immer aus einem gültigen Holen
(lesen der Daten), deren Veränderung und dem Wegschreiben. Dieser Vorgang muss auf der
unteren Schicht mit ein und demselben Handle erledigt werden.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom