Stellen Sie sich diese Situation vor:
153 )id >= 153Ist Schritt 4 sicher?
Das heißt, wenn eine andere Anforderung fast genau zur gleichen Zeit eingeht und weitere 20 Datensätze nach Schritt 2, aber vor Schritt 4 einfügt, liegt dann eine Race Condition vor?
Das heißt, wenn eine andere Anforderung fast genau zur gleichen Zeit eingeht und weitere 20 Datensätze nach Schritt 2, aber vor Schritt 4 einfügt, liegt dann eine Race Condition vor?
Ja, das wird es.
Aufzeichnungen 21 a 40 wird durch die Transaktion gesperrt 2 .
Transaktion 1 wird blockiert und wartet, bis die Transaktion 2 Übertragungen oder Rollbacks.
Wenn die Transaktion 2 Commits, dann Transaktion 1 wird aktualisiert 40 Datensätze (einschließlich derer, die durch eine Transaktion eingefügt wurden) 2 )
Ich glaube nicht, dass dies als Race Condition katalogisiert werden kann, sondern eher als ein DMBS-spezifisches Verhalten. Wenn das DBMS die neu eingefügten Datensätze sperrt, kann die erste Transaktion die Datensätze der zweiten Transaktion erst sehen, wenn die zweite Transaktion abgeschlossen ist.
Wenn die erste Transaktion die Tabelle schreibgesperrt hat, wird die zweite Transaktion beim Schreiben blockiert, bis die erste abgeschlossen ist. Ich bin mir aber nicht sicher, ob das Standard-Mysql diese Art von Funktion bietet. Ich weiß, dass MSSQL Server es tut.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
0 Stimmen
Warum sollten Sie einen separaten Aktualisierungsschritt durchführen, anstatt die korrekten Daten von vornherein einzufügen? Das ist ziemlich seltsam. Sie bräuchten sich keine Sorgen um eine "Race Condition" zu machen, wenn Sie von Anfang an die richtigen Daten eingefügt hätten. Aktualisierung von
WHERE id > 153ist auch eine sehr seltsame Anfrage. Auto increment ids haben keine Logik, und so sollten Sie nie (soweit ich weiß) nur auf der Grundlage von id aktualisieren. Und schließlich kenne ich keine "first insert id"-Funktion.0 Stimmen
@ButtleButkus dev.mysql.com/doc/refman/5.0/de/ "Wenn Sie mehrere Zeilen mit einer einzigen INSERT-Anweisung einfügen, gibt LAST_INSERT_ID() den für die erste eingefügte Zeile erzeugten Wert zurück.
0 Stimmen
Sie haben Recht mit LAST_INSERT_ID(), aber das ändert nichts an der Tatsache, dass sich die Frage auf eine hypothetische Situation zu beziehen scheint, die bei Einhaltung der grundlegenden Datenbankstruktur und -verfahren niemals eintreten würde. Warum sollte Ihr Aktualisierungskriterium jemals der Wert einer bedeutungslosen ID sein? Ich kann mir keinen Grund vorstellen. Ich würde das nicht als "Race Condition" bezeichnen, weil es unsinnig ist. Warum sollten Sie unmittelbar nach dem Einfügen aktualisieren, wenn Sie einfach die korrekten Werte einfügen könnten, um damit zu beginnen? Das sind die wahren Gründe, warum diese Frage keinen Sinn ergibt.
2 Stimmen
Ich kann mich nicht mehr an das ursprüngliche Problem erinnern (vor fast 3 Jahren), aber ich nehme an, dass es notwendig war :) Unabhängig von der Argumentation halte ich den Grundgedanken der Frage für legitim - könnten innerhalb dieser Transaktion Datensätze, die während einer dazwischenliegenden Einfügung eingefügt wurden, von einer Aktualisierung "gesehen" und beeinflusst werden?