Mich beschäftigt folgende Frage: Getriggert durch ein Formular werden in einem Script verschiedene Aktionen durchgeführt und daraufhin eine ganz enge tableupdates durchgeführt (z.Z. schätzungsweise 100-150, tendenz steigend).
Auf meinem lokalen Testssystem geht dies ruckzuck. Allerdings will ich auf nummersicher gehen und verhindern, dass sich die SQL-Befehle bei sehr zeitnaher doppelter Absendung durchmischen. Werden die beiden Blöcke von Befehlen sequentiell ausgeführt (also erst von Nutzer A getriggert, dann von Nutzer B getriggerte Aktionen) gobt es kein Problem.
In der DB-Theorie gibt es ja Sachen wie atomare Transaktionen die aber von mySQL (meines Wissens) nicht standardmässig unterstützt sind.
Ich habe jetzt rausgefunden, dass ich ein read-lock auf die tables setzen kann, der verhindert, dass andere Prozesse schreibend auf die tabelle zugreifen. Werden andereSchreibzugriffe dann serialisiert dahinter gesetzt, oder einfach ins Nirvana geschickt?
Löse ich mit diesem Read-lock mein Problem? Gibt es eine alternative Möglichkeit mein Problem zu lösen?
Die andere Frage bezieht sich auf die Performance: Da alle update-Abfragen auf die selbe table zielen, wie kann ich es erreichen, dass die Befehle "gepuffert" und dann am Stück ausgeführt werden. Ich habe dazu nur den Befehl "UPDATE LOW_PRIORITY table blah" gefunden, wird es das gewünschte tun und kann ich das zusammen mit einem lock verwenden? Gibts Probleme oder evtl. noch einen anderen Befehl?
Danke im voraus.
:).