Datenbank Race Conditions

Question

Ich habe von vielen Anwendungsentwicklern gehört, die ein bisschen Probleme in Bezug auf Race-Bedingungen in der Datenbankverarbeitung haben. Ein typisches Beispiel geht in etwa so:

• Benutzer 1 ein Feld auswählt, sagen wir, numStock, die 3
• Benutzer 2 auch wählt numStock, die noch 3
• Benutzer 1 dekrementiert numStock (in der app) und setzt es auf 2 in der Datenbank.
• Benutzer 2 dekrementiert auch numStock (in der App) und setzt es auf 2 in der Datenbank.

In diesem Beispiel sollte das Feld numStock 1 werden, wurde aber aufgrund des Wettrennens zwischen Benutzern auf 2 gesetzt.

Also natürlich können Sperren verwendet werden, aber ich habe über eine andere Art der Handhabung nachgedacht - alle Zeilendetails als WHERE-Kriterium übergeben. Lassen Sie mich erklären ...

In dem obigen Beispiel könnte die SQL-Codes wie folgt aussehen:

//

wählen

SELECT itemID, numStock FROM items WHERE itemID = 45 

// aktualisieren

UPDATE items SET numStock = 2 WHERE itemID = 45 

Meine Idee für Lösen des Rennens:

// wählen

SELECT itemID, numStock FROM items WHERE itemID = 45 

// Update

UPDATE items SET numStock = 2 WHERE itemID = 45 AND numStock = 3 

So können die Abfrage prüft, ob die Daten geändert hat, seit er die Daten SELECT-ed. Also meine Frage ist: (1) Würde das [immer] funktionieren? und (2) ist dies eine bessere Option im Vergleich zu Datenbanksperrmechanismen (z. B. MySQL-Transaktionen)?

Danke für Ihre Zeit.

Answer 1

Diese Strategie funktioniert und wird als "optimistisches Sperren" bezeichnet. Das ist, weil Sie Ihre Verarbeitung davon ausgehen, dass es erfolgreich sein wird und nur am Ende tatsächlich überprüfen, ob es erfolgreich war.

Natürlich brauchen Sie eine Möglichkeit, die Transaktion erneut zu versuchen. Und wenn die Ausfallwahrscheinlichkeiten sehr hoch sind, könnte es ineffizient werden. Aber in den meisten Fällen funktioniert es gut.