System zu schnell

[Rolf B]

Hallo Pit,

will man einen Timestamp für optimistisches Locking verwenden, nimmt man (MySQL) nicht TIMESTAMP, sondern TIMESTAMP(6) und definiert die Spalte mit DEFAULT NOW(6) ON UPDATE NOW(6). Dann sind die Timestamps auf Millionstelsekunden genau - fraglich ist allerdings, ob der MySQL Server auch einen Mikrosekundengenauen internen Timer hat. Der wird vom Betriebssystem kommen und ist damit eine Größe variabler Genauigkeit.

Besser für optimistisches Locking ist aber eine Satzversionsnummer, die man beim Lesen dem Editierer übergibt und die man beim Schreiben hochzählt.

Beim Schreiben gibt man im WHERE die fachlichen eindeutigen Suchbegriffe an und dazu eine Abfrage, ob die Versionsnummer gleich geblieben ist. Wenn nicht, wurde konkurrierend geändert. Die Versionsnummer muss gar nicht so groß werden, da reicht ein short Integer, den man mit version = MOD(version + 1, 32768) hochzählt. Es müsste schon während eines Edit-Intervalls 32K Updates auf den gleichen Satz geben, um das zu brechen, und wenn Du eine solche Edit-Frequenz ERWARTEST, dann nimmst Du halt den Timestamp des Satzes noch hinzu.

Die Verwendung einer außerhalb des Servers generierten, zufälligen "unique id" ist für optimistisches Locking nicht sinnvoll. Zufallszahlen können immer kollidieren, insbesondere wenn die Server im Cluster laufen. Ein sekundengenauer Timestamp ist komplett Banane (wobei man den Parameter für TIMESTAMP und NOW im MySQL Handbuch durchaus überlesen kann), ein Mikrosekunden-Timestamp sollte funktionieren, setzt aber einen Server voraus, der das auch liefert. Mit der Satzversion bist Du auf der sicheren Seite.

Rolf