0

Ich würde gerne wissen, wenn es ein echtes Fall-Szenario gibt, in dem Race-Condition-Probleme tatsächlich bei einer Einfügeabfrage auftreten können. Also ich habe eine Tabelle „User“ mit den folgenden Feldern:MySQL-Einfügung: Race-Bedingung

User: 
iduser | idcompany | name | email 

Ich benutze einen zusammengesetzten Primärschlüssel für diese Tabelle, die ist (iduser, idcompany). Keines dieser Felder ist auf AUTO_INCREMENT eingestellt. Ich bekomme den Wert des Feldes "IDCompany" durch eine Session-Variable, so dass es kein echtes Problem gibt. Allerdings benutze ich eine getNextUserId() gibt den nächsten gültigen iduser Wert durch eine ausgewählte Abfrage wie folgt zu erhalten:

SELECT MAX(iduser) + 1 AS next_iduser FROM User WHERE idcompany = {myCompanyId}; 

Ich frage mich, ob es ein Fall, in dem eine doppelte Kombination von (iduser, idcompany) sein könnte aufgrund der Race Condition in die Datenbank eingefügt und wie ist dieses Szenario möglich? Blockiert MySQL die Tabelle beim Einfügen nicht? Wäre nicht eine doppelte Kombination von (iuser, idcompany) einfach abzulehnen oder könnte ich wirklich einen doppelten Primärschlüssel in meiner Tabelle haben? Ich bin mir bewusst, Strategien zu verhindern Race-Zustand wie AUTO_INCREMENT Primärschlüssel, mit SQL-Transaktionen oder manuell sperren die "User" -Tabelle, aber ich möchte den Mechanismus hinter einer möglichen Race-Bedingung in diesem Fall verstehen und was sind die wirklichen Probleme in diese Implementierung. Momentan muss keines dieser Felder aus offensichtlichen Gründen in meiner Tabelle eindeutig sein, aber ich würde gerne wissen, ob eine UNIQUE-Einschränkung für den iuser das Szenario, dem ich gegenüberstehe, verändern würde und warum dies geschieht.

+0

Es sperrt während der Einfügung, aber nicht während 10 Benutzer aus dem gleichen Unternehmen versuchen, sich zu registrieren, und Sie die SELECT ausführen müssen, um die nächste ID zu finden, die 10 Mal ohne Sperre verwendet wird. Sie sollten dies wirklich in einer Transaktion tun, aber das setzt voraus, dass Sie PDO oder MYSQLI verwenden und die Datenbanktabellen INNODB sind. – RiggsFolly

+1

Sie können vielleicht einen Blick auf 'SELECT ..... WITH LOCK' werfen [hier in der Anleitung] (http://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html) – RiggsFolly

+0

Wie ich ausdrücklich in meiner Frage sage, suche ich nicht nach einer Lösung für mein Problem, ich versuche es verstehe die möglichen Konsequenzen meiner Implementierung. Bill Karwin weist in seinem Buch "SQL Antipatterns" darauf hin, dass diese Praxis zu Rennbedingungen führen würde, also versuche ich herauszufinden, welche Szenarien in diesem Fall möglich sind. – iiirxs

Antwort

0

Sie haben geschrieben, dass Sie einen zusammengesetzten Primärschlüssel auf iduser, idcompany Felder hatten. Diese Einschränkung verhindert, dass die Tabelle doppelte IDuser-ID-Firmenpaare aufweist. Das Schlimmste, was ohne Sperren passieren könnte, ist, dass die Erstellung eines Benutzers durch die Verletzung des Primärschlüssels verhindert wird.

+0

Also könnte ich nie ein Duplikat Paar haben, auch wenn Race Condition auftritt? Kann meine aktuelle Implementierung akzeptabel sein? – iiirxs

+0

Etwas verwandt: http://StackOverflow.com/a/6477687 – Drew

+1

Diese spezifische Race-Bedingung kann perfekt durch die Constrained Constraint-Primärschlüssel (oder eindeutiger Index) Constraint behandelt werden. – Shadow

Verwandte Themen