The so-called oversold phenomenon example: for example, the inventory of a commodity is 1, when users 1 and 2 concurrent purchase of the product, user 1 after the order to submit the goods inventory is modified to 0, and when the user 2 do not know the circumstances of the submission of the order, the inventory of the goods is again modified to 1 This is the phenomenon of oversold.
The underlying reason is that the database bottom of the write operation and read operations can be done at the same time, although the write operation by default with an implicit lock (that is, the same data can not write at the same time) but the read operation is not with the lock, so when the user 1 to modify inventory, user 2 can still be inventory 1, so there is oversold phenomenon
Solution:
You can add an explicit lock to a read operation (that is, in select ... Statement at the end of the add for update) so that user 1 reads, user 2 needs to be queued.
But the problem comes, if the product is very popular concurrency is very high then the efficiency will be greatly reduced, how to solve.
Solution:
We can have the choice to have the option to lock on the read operation, for example, can make a judgment on the inventory, when the inventory is less than a volume to start locking, so that buyers queue, which solves the oversold phenomenon.