Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #3486

Re: Datenbankzugriffe

Show all headers | View raw

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Karl Pflästerer wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Karl Pflästerer wrote:
>>>> Niels Braczek <nbraczek@freenet.de> writes:
>>>>> Eine schnelle Alternative ist das Cachen im Dateisystem. Wenn du die
>>>>> Cache-Datei löschst, sobald sich an der Konfiguration etwas ändert,
>>>>> kannst du den Cache auch Session-übergreifend nutzen.
>>>> 
>>>> Ein weiterer Vorteil ist, dass man diese Cache Datei gezielt dann
>>>> schreiben kann, wenn sich etwas ändert. So ist sie immer aktuell.
>>>> 
>>>> So muss man nie löschen, sondern überschreibt (mit rename wegen race
>>>> conditions).
>>>
>>> Wie schon anderswo geschrieben: Das Umbenennen (”rename”) löst das
>>> Problem der Race Condition nicht, es verschärft es sogar.
>> 
>> Wo steht das?
>> 
>> Unter Linux ist ein rename atomar,
>
> Wie kommst Du darauf, dass PHP nur unter Linux läuft?

Linux, BSD, Unix sind die hauptsächlichen *Server* BS in diesem Bereich.

>> da gibt es keine race condition (Lesen von partiellem content).
>
> Die Race Condition ist, dass ein Prozess auf eine Datei schreiben könnte, 
> die ein anderer Prozess lesend geöffnet hat; nicht das „Lesen von partiellem 
> Content“.

Möglich. Aber darauf bezog ich mich gerade *nicht*. rename habe ich
nicht zufällig genannt. temp datei + rename ist ein gängiges Muster
unter unixoiden Systemen.

>> Man öffnet eine temporäre Datei, schreibt in diese und benennt diese
>> Datei am Ende um. So sehen alle lesenden Zugriffe immer eine
>> vollständige Datei.
>
> Das ist noch immer vom Dateisystem und nicht nur vom Betriebssystem 
> abhängig.

man 2 rename


>>> Sessions (zum Lesen und Speichern) und globale Variablen (zum Lesen) sind
>>> hier der richtige, das Speichern im Dateisystem der falsche, Ansatz.
>> 
>> IBTD. Zum einen ist es mit Sessions nicht so einfach Config Änderungen
>> für alle gleichzeitig sichtbar sein zu lassen;
>
> Das ist auch nicht nötig.  Es wird beim Start der Applikation einmalig die 
> Session-Variable mit den Daten befüllt, und bei jedem Request wieder, wenn 
> sich die Daten geändert haben sollten.

Dann muss man immer prüfen, ob sich etwas geändert hat; das kostet mehr
(typischerweise ein DB Zugriff, den man ja gerade vermeiden wollte) als
immer eine zentrale Config einzulesen (oder aus Redis oder Memcache oder ...)

>> zum anderen ist der Standard Speicherort von Sessions das Dateisystem.
>
> Aber nicht der einzige.
>
>> Der Unterschied ist hier nur, ob nutzerspezifisch gecached werden soll.
>
> Mit Sessions hat jeder Benutzer automatisch seine eigene Datei.

Das ist der Sinn von Sessions. Aber eben auch der Nachteil, wenn man
*nicht* nutzerspezifische Daten hat, die man möglichst schnell
aktualisieren möchte. Dann *können* andere Mechanismen bequemer sein.

Back to de.comp.lang.php | Previous | Next — Previous in thread | Find similar

Thread

Re: Datenbankzugriffe k@rl.pflaesterer.de (Karl Pflästerer) - 2015-07-20 14:05 +0200
  Re: Datenbankzugriffe Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-07-28 20:52 +0000
  Re: Datenbankzugriffe k@rl.pflaesterer.de (Karl Pflästerer) - 2015-07-29 06:59 +0200

csiph-web