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 rows don't get updated by other users. It's suitable for the update heavy applications (many users making the possibility of more concurrency issues) on relative small amount of records. It has some complexities in implementations which if not done properly often results in deadlock.
Comments