System Design: Database Transactions, Isolation Levels, Concurrency Control Cont’d. (Part 3)
So this blog is in continuation of my previous blog on Database Transactions, Isolation Levels, Concurrency Control Cont’d. (Part 2) and If you haven’t read my previous blog on this topic then I will highly recommend reading the previous part here.
So till now let’s discuss what we have covered so far in our previous blogs.
- Read Committed Isolation level with its issues
- Algorithm to implement Read Committed
- Repeatable Read Isolation level with its issues
- Algorithm to implement Repeatable Read
As we have already seen even in Repeatable Read or Snapshot Isolation Level there is an issue of Write Skew race condition.
Now let’s discuss the last and the strongest Isolation level which Serializable
Serializable Isolation
In Serializable Isolation, execution of concurrent transactions produces the same effect or result as these same transactions were executed serially. A serial execution is one in which each transaction executes to completion before the next transaction begins.
And finally, Serializable Isolation is our savior from all the concurrency issues that exist in our universe.
But the performance tradeoff is very high here.
Even some of you might wonder do we have any concurrency left in this Isolation?
Implementing Serializable isolation
The simplest way of avoiding concurrency problems is to remove the concurrency entirely (LOL :P)
To execute only one transaction at a time, in serial order, on a single thread. By doing so, we completely sidestep the problem of detecting and preventing conflicts between transactions.
The approach of executing transactions serially is implemented in VoltDB/H-Store, Redis, and Datomic. A system designed for single-threaded execution can sometimes perform better than a system that supports concurrency because it can avoid the coordination overhead of locking. However, its throughput is limited to that of a single CPU core.
Again this answers one of the questions that I asked in my previous blog
How In-Memory Databases like Redis etc handle or prevent concurrency issues or race conditions?
So Redis is single-threaded. Redis operations are atomic is simply a consequence of the single-threaded event loop. It provides concurrency by having non-blocking I/O (NIO) just like in NodeJs.
Hence all transactions are executed serially on a single thread. You can read more about it here.
So, for now, I think that’s pretty much about Database Transactions & Isolation levels.
Yes, I know you folks might be wondering what about are the other topics like What is Optimistic and Pessimistic concurrency control, Two-phase commit (2PL) mechanism that I promised to discuss.
Don’t worry, so the next blog I will write in continuation of this blog which will cover the remaining topics.
Till then stay tuned and keep reading. Moreover, if you have any doubts you can connect with me on Linkedin, Github, Twitter, Facebook. And if you liked this article then please share and follow.
Further Reading
- Redis is single-threaded then how does it do concurrent IO. You can read about it here
- NodeJs nonblocking & single-threaded architecture here
- Concurrency control in ORMs likes Hibernate. You can read about it here
