The semantics of the SQL you wrote depends on the transaction isolation level and flavour of transaction implementation. Read committed vs repeatable read (common terms for specific semantics) makes a difference as to what selects can see with respect to concurrent transactions. The way the SQL is written can also affect how reads and writes interleave.
Repeatable read isn't super-expensive in modern databases with MVCC support - these should prevent the situation in the article if the SQL is as simple as you write.
There's a strong hint that it isn't, though; there appears to be a two-phase state machine involved, with two requests. No sane developer will write a transaction that starts in one request and commits in another.
Repeatable read isn't super-expensive in modern databases with MVCC support - these should prevent the situation in the article if the SQL is as simple as you write.
There's a strong hint that it isn't, though; there appears to be a two-phase state machine involved, with two requests. No sane developer will write a transaction that starts in one request and commits in another.