SQL im __destruct(or)
=====================

An sich keine schlechte Sache: Man hat zum Beispiel eine PHP-Klasse „Nutzer“,
die beim Zerstören einer Instanz automatisch ein paar Sachen wie „Letzer
Login“, „Letzte Aktivität“ und ähnliches in die Datenbank schreibt. Das
funktioniert auch recht gut, sofern keine Exceptions auftreten:

	Note: Attempting to throw an exception from a destructor (called in the
	time of script termination) causes a fatal error. 

	-- http://www.php.net/manual/en/language.oop5.decon.php

Bei einigen Nutzern tritt aber, zunächst ohne ersichtlichen Grund, ein Problem
auf: Die Daten, die in der Datenbank landen „stimmen irgendwie nicht“. Dann
fällt auf, dass der Destruktor insgesamt öfter als gedacht aufgerufen wird.
Ach ja: Direkt auf der Startseite, also nach dem Login, werden die neusten
Benutzer angezeigt. Für die wird je eine Instanz der Klasse erstellt.

Und ausgerechnet diese Nutzer sind es, bei denen unsinnige Werte für den
letzten Login in der Datenbank stehen. Anscheinend werden *zwei* Instanzen der
Klasse „Nutzer“ für denselben Benutzer erstellt und – in ungünstiger
Reihenfolge – wieder zerstört. Dadurch gelangt der nicht aktualisierte Wert
für den letzten Login immer wieder in die Datenbank, denn nur eine der beiden
Instanzen wird in dieser Hinsicht aktualisiert.

Das Verhalten erinnert ein wenig an eine sogenannte „Race-Condition“, bei der
das Gesamtergebnis von der Ausführungsreihenfolge einzelner Befehle abhängt.
In diesem Fall sind es allerdings keine parallel ausgeführten Prozesse mit
einzelnen, nicht-atomaren Befehlen, die das unvorhersehbare Verhalten
hervorrufen – was gegen die Verwendung des Begriffs „Race-Condition“ spricht.

Fazit und Problemlösung: Entweder *niemals* zwei Instanzen einer Klasse
erzeugen, die sich auf denselben Datensatz beziehen oder Schreibvorgänge nur
explizit anstoßen, etwa mit einer Prozedur ``save ()``, nicht aber in den
Destruktor verlagern.