3 ms·
I presume that a DB lock for the length of the request processing time would cause contention when the number of concurrent session requests increases (with use
by robocat 3y ago
I presume that a DB lock for the length of the request processing time would cause contention when the number of concurrent session requests increases (with user growth).
The article mentions this example:
Some data structures aggressively tackle concurrency issues by using locking to only allow a single worker to access them at a time. One example of this is PHP's native session handler - if you send PHP two requests in the same session at the same time, they get processed sequentially! This approach is secure against session-based race conditions but it's terrible for performance, and quite rare as a result.
- josephg 3y agoThis is a misconception about how transactions are implemented by the database. Unlike php, a lot of modern databases implement transactions without locking out other concurrent queries from being executed at the same time. In serializable (linearizable?) databases, everything happens as if the queries happened one at a time, but using magic tricks like MVCC they don’t need to lock the database to do it. It’s cool stuff! So long as your transactions are short lived it usually performs way better than you’d expect. Modern databases are incredible feats of engineering.
- krackers 3y agoAlso optimistic locking