Quite often in database processing, we come across the situation wherein one transaction
can change a value, and a second transaction can read this value before the original
change has been committed or rolled back. This is known as a dirty read
scenario because there is always the possibility that the first transaction may rollback
the change, resulting in the second transaction having read an invalid value.
While you can easily command a database to disallow dirty reads, this usually degrades
the performance of your application due to the increased locking overhead. Disallowing
dirty reads also leads to decreased system concurrency.