When I see this answer I was left with this question:
If we have 2 transactions to be handled at the same time, in the first one (A) we are writing to table x, in the second (B) if we try to write to table x at the same time, what happens?
As writing can be update , insertion or removal :
Depending on the case, the second transaction will be blocked until the first transaction ends.
Some engines of MySQL like InnoDB support row-level locking ), while in others locking is per page or across the table.
So in a well-configured bank, two transactions can write to the same table without any locking on execution, as long as they are not changing the same record.
Specifically about the response quoted, it deals a lot with isolation levels, ie as a B transaction sees data that is changed by a A parallel transaction. Depending on the configuration, the B transaction can see data not yet committed by the A transaction. In another configuration, the B transaction sees the original data, as if A did not exist.
Anyway, I will not detail the answer again, but that's the idea.
On the issue of Simultaneous INSERTS , if the table uses auto increment, as per the documentation , this generates an exclusive lock until the end of the transaction. However, using keys generated by some other source will not have competition problems.
If the engine is InnoDB and the isolation level is READ LOCAL , according to documentation , you can do simultaneous inserts.
For MyISAM tables there is a parameter called concurrent_inserts to define how many transactions are allowed to be inserted at the same time.
In the case of removal ( DELETE ) or update ( UPDATE ), generally new transactions attempting to execute actions will be blocked when there is a transaction in progress having the "right" on the records in question > lock ).
