ЗАПРАВКИ НЕ ВИНАГИ СЕ ИЗПЪЛНЯВАТ ПАРАЛЕЛНО
Зависи от двигателя на базата данни. С MyISAM почти всяка заявка придобива заключване на ниво таблица, което означава, че заявките се изпълняват последователно като опашка. С повечето други двигатели те могат да работят паралелно.
echo_me казва nothing happens at the exact same time and a CPU does not do everything at once
Това не е точно вярно. Възможно е СУБД да работи на машина с повече от един процесор и с повече от един мрежов интерфейс. Това емного малко вероятно е 2 заявки да пристигнат едновременно - но не е невъзможно, следователно има мютекс, който да гарантира, че преходът за изравняване/изпълнение се изпълнява само като една нишка (на изпълнение - не е задължително със същия лек процес).
Има 2 подхода за решаване на едновременен DML - или за използване на транзакции (където всеки потребител ефективно получава клонинг на базата данни) и когато заявките са завършени, СУБД се опитва да съгласува всички промени - ако съгласуването е неуспешно, тогава СУБД връща обратно един от заявките и го докладва като неуспешен. Другият подход е да се използва заключване на ниво ред - СУБД идентифицира редовете, които ще бъдат актуализирани чрез заявка и ги маркира като запазени за актуализиране (другите потребители могат да прочетат оригиналната версия на всеки ред, но всеки опит за актуализиране на данните ще бъде блокиран, докато редът е наличен отново).
Проблемът ви е, че имате два клиента на mysql, всеки от които е възстановил факта, че е останал един артикул на склад. Това допълнително се усложнява от факта, че (тъй като споменавате PHP) нивата на запасите може да са били извлечени в различна сесия на СУБД от последващата корекция на запасите - не можете да имате транзакция, обхващаща повече от HTTP заявка. Следователно трябва да потвърдите повторно всеки факт, поддържан извън СУБД в рамките на една транзакция.
Оптимистичното заключване може да създаде псевдо - механизъм за контрол на транзакциите - маркирате запис, който предстои да промените, с времева марка и потребителски идентификатор (с PHP идентификаторът на сесията на PHP е добър избор) - ако когато дойдете да го промените, нещо друго го промени, тогава кодът ви знае, че данните, които е изтеглил преди, са невалидни. Това обаче може да доведе до други усложнения.
