FORSØGNINGER KØRER IKKE ALTID PARALLELT
Det afhænger af databasemotoren. Med MyISAM får næsten hver forespørgsel en tabelniveaulås, hvilket betyder, at forespørgslerne køres sekventielt som en kø. Med de fleste af de andre motorer kan de køre parallelt.
echo_me siger nothing happens at the exact same time and a CPU does not do everything at once
Det er ikke helt rigtigt. Det er muligt, at et DBMS kan køre på en maskine med mere end én cpu og med mere end én netværksgrænseflade. Det er meget usandsynligt, at 2 forespørgsler kunne ankomme på samme tid - men ikke umuligt, derfor er der en mutex for at sikre, at paring/execution-overgangen kun kører som en enkelt tråd (af udførelse - ikke nødvendigvis den samme letvægtsproces).
Der er 2 tilgange til at løse samtidig DML - enten at bruge transaktioner (hvor hver bruger effektivt får en klon af databasen), og når forespørgslerne er afsluttet, forsøger DBMS at afstemme eventuelle ændringer - hvis afstemningen mislykkes, så ruller DBMS en af forespørgslerne og rapporterer det som mislykket. Den anden tilgang er at bruge rækkeniveaulåsning - DBMS identificerer rækkerne, som vil blive opdateret af en forespørgsel og markerer dem som reserveret til opdatering (andre brugere kan læse den originale version af hver række, men ethvert forsøg på at opdatere dataene vil blive blokeret, indtil rækken er tilgængelig igen).
Dit problem er, at du har to mysql-klienter, som hver har hentet det faktum, at der er en vare tilbage på lager. Dette kompliceres yderligere af det faktum, at (siden du nævner PHP) lagerniveauerne kan være blevet hentet i en anden DBMS-session end den efterfølgende lagerjustering - du kan ikke have en transaktion, der spænder over mere end HTTP-anmodning. Derfor skal du genvalidere enhver kendsgerning, der vedligeholdes uden for DBMS, inden for en enkelt transaktion.
Optimistisk låsning kan skabe en pseudo - transaktionskontrolmekanisme - du markerer en post, du er ved at ændre med et tidsstempel og bruger-id'et (med PHP er PHP-sessions-id'et et godt valg) - hvis, når du kommer til at ændre det, noget andet har ændret det, så ved din kode, at de data, den tidligere har hentet, er ugyldige. Dette kan dog føre til andre komplikationer.