This post takes the DB transaction discussion to one step further. Two ways the application developers handle DB concurrency are optimistic locking and pessimistic locking. While transaction isolation levels are used to implement pessimistic locking, optimistic level is implemented using versioning and timestamp columns. More details on these concurrency measures are provided below. Optimistic Locking : As the name suggests, it takes an optimistic approach. It allows the concurrency issues to happen and then takes actions to handle that. Hence, there is no preventive measure. It is suitable for a database having relatively large number of records and less users making concurrency possibility low. It doesn't lock the rows, but used version or timestamp columns to check for updates. It's pretty easy to implement. Pessimistic Locking : This is in total opposite to the optimistic locking, here it prevents the concurrency issues beforehand by locking the DB rows so that these...
This post is dedicated to another important topic related to DB, the 'Transaction Isolation Levels'. There are four different types of transaction isolation levels. While most of the databases support all these four, but some like PostGRES do not support all. Isolation levels controls how much of the uncommitted data from a particular transaction is visible to other transactions. Before delving more into various isolation levels, lets try to understand various scenarios of inconsistencies that occur when two or more transactions operate on the same data at the same time. Dirty Read : This is the case when one transaction reads the data which contains uncommitted data from other transaction. If the other transaction rolls back the operation, the first transaction still has that invalid data which leads to inconsistencies. Non-repeatable Read : This occurs when a same query inside same transaction leads to different results if executed repeatedly. In such situations, one tran...