Noch nicht so ganz, muss ich zugeben... wo fangen wir denn nu an? Datenbanken und auf Festplatte schreiben: Natürlich muss alles, was in einer DB geschrieben wird, irgendwann (besser früher als später) auch auf Platte landen. Die meisten mir bekannten DB-Systeme verfügen aber IMHO auch über Cache-Mechanismen, um wiederholte Zugriffe auf gleiche Daten zu beschleunigen und bei multiplen Änderungen in kurzer Zeit diese erstmal im Arbeitsspeicher auszuführen, bevor das Resultat auf Platte geschrieben wird. Zumindest sofern man sich nicht in kritischen Bereichen wie z.B. Banken befindet, in denen es essentiell ist, dass jede vorgenommene Änderung auch wirklich auf der Festplatte landet, damit sich die DB jederzeit in einem konsistenten Zustand befindet, der zu den vorgenommenen Transaktionen passt. Der Einsatz einer zusätzlichen Zwischenspeicherlösung wie z.B. Memcached sorgt doch lediglich dafür, dass man nochmal von Hand eine weitere Cache-Ebene dazunimmt. Kann in manchen Fällen sicher beschleunigend wirken, insb. bei Web-Anwendungen, hat aber m.E. mit dem eigentlichen Problem immer noch nicht wirklich viel zu tun. Und das genannte Beispiel mit den parallelen SELECT und UPDATE-Anweisungen ist insofern kein wirkliches Argument, da auch Datenbanken normalerweise Locking-Mechanismen verschiedener Art mitbringen. Und schon hat man das Problem der Racing Conditions in Datenbanken wieder auf das allgemeine Problem übertragen. Man muss die Locking-Mechanismen nur als Entwickler auch konsequent einsetzen. -- Snuffels 11:27, 26. Jan. 2010 (CET)