LAS CONSULTAS NO SIEMPRE SE EJECUTAN EN PARALELO
Depende del motor de la base de datos. Con MyISAM, casi todas las consultas adquieren un bloqueo de nivel de tabla, lo que significa que las consultas se ejecutan secuencialmente como una cola. Con la mayoría de los otros motores, pueden funcionar en paralelo.
echo_me dice nothing happens at the exact same time and a CPU does not do everything at once
Eso no es exactamente cierto. Es posible que un DBMS pueda ejecutarse en una máquina con más de una CPU y con más de una interfaz de red. Es muy es improbable que lleguen 2 consultas al mismo tiempo, pero no imposible, por lo tanto, hay un mutex para garantizar que la transición de emparejamiento/ejecución solo se ejecute como un único subproceso (de ejecución, no necesariamente el mismo proceso ligero).
Hay 2 enfoques para resolver DML concurrentes:usar transacciones (donde cada usuario obtiene efectivamente un clon de la base de datos) y cuando las consultas se han completado, el DBMS intenta reconciliar los cambios; si la reconciliación falla, el DBMS revierte uno de las consultas y lo informa como fallido. El otro enfoque es utilizar el bloqueo a nivel de fila:el DBMS identifica las filas que se actualizarán mediante una consulta y las marca como reservadas para actualización (otros usuarios pueden leer la versión original de cada fila, pero cualquier intento de actualizar los datos será rechazado). bloqueado hasta que la fila vuelva a estar disponible).
Su problema es que tiene dos clientes mysql, cada uno de los cuales ha recuperado el hecho de que queda un artículo en stock. Esto se complica aún más por el hecho de que (dado que menciona PHP) los niveles de existencias pueden haberse recuperado en una sesión de DBMS diferente a la del ajuste de existencias posterior:no puede tener una transacción que abarque más de una solicitud HTTP. Por lo tanto, necesita revalidar cualquier hecho mantenido fuera del DBMS en una sola transacción.
El bloqueo optimista puede crear un pseudo - mecanismo de control de transacciones:marca un registro que está a punto de modificar con una marca de tiempo y el identificador de usuario (con PHP, la ID de sesión de PHP es una buena opción), si cuando llega a modificarlo, algo más lo ha cambiado, entonces su código sabe que los datos que recuperó previamente no son válidos. Sin embargo, esto puede conducir a otras complicaciones.
