nicht angemeldet
Rolf bDas ist richtig, man muss Inserten und dann prüfen. Es bleibt aber mit der Routine immerhin im SQL Server und kostet daher weniger Turnaround-Zeit.
Ein Table-Lock ist riskant, wenn es einen Run auf den Server gibt. Man will schreiben, braucht also einen Write-Lock, und das führt zu einer Serialisierung aller Zugriffe, inclusive der lesenden. Das skaliert dann nicht im geringsten, damit fackelt man keine 600.000 Server Requests in einer Stunde ab. In dem Fall hilft auch keine Webserver-Farm, weil die DB den Engpass bildet.
Wieweit einem ein Pre-Insert Trigger auf die atomaren Beine helfen kann, weiß ich nicht.
Ich finde aber gerade noch den SELECT FOR UPDATE Befehl von MySQL, damit liest man eine Row und sperrt sie sofort für Updates. Es setzt sinnvollerweise voraus, dass man InnoDB als Database Storage Engine verwendet, und eine Transaktion starten muss man natürlich auch. Das TOCTTOU Problem sollte sich damit nicht stellen. Man KANN auf diese Weise freie Plätze reservieren (wenn man eine Row pro Platz hat), oder einen Tisch, um dann daran die freien Plätze auf den neuen Stand zu bringen.
Bevor Du mit deiner Lösung live gehst, MUSST Du Dir überlegen, wie Du das Produkt lasttestet. Ggf. brauchst Du Scripte, die nichts weiter tun als in kürzester Zeit die entsprechenden Requeste für Tischreservierungen aufzurufen. Mir sagte mal einer: Das schlimmste, was einem im Web passieren kann, ist Erfolg. Weil man dann auf einmal merkt, wo die Site in Last-Engpässe gerät :)
Rolf
TS
Matthias Apsel