LE QUERY NON VENGONO SEMPRE ESEGUITE IN PARALLELO
Dipende dal motore di database. Con MyISAM, quasi tutte le query acquisiscono un blocco a livello di tabella, il che significa che le query vengono eseguite in sequenza come una coda. Con la maggior parte degli altri motori possono funzionare in parallelo.
echo_me dice nothing happens at the exact same time and a CPU does not do everything at once
Non è esattamente vero. È possibile che un DBMS possa essere eseguito su una macchina con più di una CPU e con più di un'interfaccia di rete. È molto improbabile che 2 query possano arrivare contemporaneamente - ma non impossibile, quindi c'è un mutex per garantire che la transizione di associazione/esecuzione venga eseguita solo come un singolo thread (di esecuzione - non necessariamente lo stesso processo leggero).
Esistono 2 approcci per risolvere DML simultanei:utilizzare le transazioni (in cui ogni utente ottiene effettivamente un clone del database) e quando le query sono state completate, il DBMS tenta di riconciliare eventuali modifiche:se la riconciliazione non riesce, il DBMS esegue il rollback di uno dei le query e lo segnala come non riuscito. L'altro approccio consiste nell'utilizzare il blocco a livello di riga:il DBMS identifica le righe che verranno aggiornate da una query e le contrassegna come riservate per l'aggiornamento (gli altri utenti possono leggere la versione originale di ogni riga ma qualsiasi tentativo di aggiornare i dati sarà bloccato fino a quando la riga non sarà nuovamente disponibile).
Il tuo problema è che hai due client mysql, ognuno dei quali ha recuperato il fatto che è rimasto un articolo di scorta. Ciò è ulteriormente complicato dal fatto che (poiché menzioni PHP) i livelli delle scorte potrebbero essere stati recuperati in una sessione DBMS diversa rispetto alla successiva regolazione delle scorte:non puoi avere una transazione che si estende oltre la richiesta HTTP. Quindi è necessario riconvalidare qualsiasi fatto mantenuto al di fuori del DBMS all'interno di una singola transazione.
Il blocco ottimistico può creare uno pseudo - meccanismo di controllo della transazione - contrassegni un record che stai per modificare con un timestamp e l'identificatore utente (con PHP l'ID di sessione PHP è una buona scelta) - se quando arrivi a modificarlo, qualcos'altro lo ha modificato, il tuo codice sa che i dati recuperati in precedenza non sono validi. Tuttavia questo può portare ad altre complicazioni.
