nicht angemeldet
Hello,
genau das habe ich vermutet. War anfänglich kein Problem, da nur zwei, drei Spieler täglich das Quiz (darum geht es) spielten, gestern Abend z.B. jedoch gleich 5 Spieler gleichzeitig.
Bei vernünftig schnellen Servern kommen die Probleme meistens erst bei mehr als 50 Zugriffen in der Sekunde. Sven Rautenberg hatte da mal mein Demoscript http://bitworks.de/~selfHTML/speichern.php mit ca. 130 Zugriffen die Sekunde gekillt, bevor es die flocks erhalten hat.
Da man die Datei nicht löscht, bevor sie nei geschreiben wird, empfihlt es sich, den ggf. überstehenden Rest nach dem Neuschreiben mit ftruncate() wieder abzuschneiden.
Im meinem konkreten Fall dürfte das zwar nicht nötig sein (es sind immer gleich viele Records mit gleicher Länge), aber sicher ist sicher ...
Die gleiche Länge lässt sich nur gewährleisten, wenn man mit einer *_pad() Funktion immer brav auffüllt oder mit pack() und unpack() arbeitet. dann könntest Du auch satzweises Schreiben ermöglichen und Satzsperren (über eine andere Tabelle) setzen.
Zusatz-Frage: Gehe ich recht in der Annahme, dass, solange das File gesperrt ist, die weiteren Zugriffe anderer User automatisch in eine "Warteschlange" gesetzt werden, bis das File wieder entsperrt ist?
Das macht die Funktion flock(), wenn man sie ohne LOCK_NB benutzt. Die hält das Script, dass sperren will, solange an, wis sie true zurückgeben kann, oder bis TimeOut erreicht ist. Letzteres habe ich aber noch nicht ausprobiert, wie lange das effektiv dauert. Wenn man flock also auf die billige verwendet, kann man ggf. bei einem Deadlock (google mal danach) seine 150 Intanzen vom Apachen locker dicht machen.
Die TimeOut-Zeit ist sicher nur die Netto-rechenzeit und flock() geht zwischendurch immer in eine idle-Sequenz ( sleep() ), und die zählt nicht zur Rechenzeit oder sorgt sogar dafür, dass diese von vorne anfängt zu zählen.
Liebe Grüße aus http://www.braunschweig.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen