I'm doing some research on database isolation levels and which allow dirty reads through isolation level READ UNCOMMITTED. The advantage seems to be speed and latency but at the cost of accuracy and consistency. My question for the community is if allowing Dirty Reads is preferred?
Ask HN: Dirty Reads for Databases: Good Thing or Bad?
1–9 of 9 posts
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#2I'm certainly not the most knowledgeable in this at all, but if I'm not mistaken most environments I've worked in have been only the dev instance allows it, while UAT and production won't allow any dirty reads.
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#3I'm certainly not the most knowledgeable in this at all, but if I'm not mistaken most environments I've worked in have been only the dev instance allows it, while UAT and production won't allow any dirty reads.
It depends. A couple databases have a default isolation level that allow dirty reads. Most SQL databases allow you to manually change the isolation level or ReadConcern level to allow Uncommitted Reads if you choose.
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#4Since the transaction that did the write is uncommitted, dirty reads are generally a bad idea as you may act based on something that is subsequently thrown away.
Only useful use I've found for them: emulating sequences on a DB without them.
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#5Since the transaction that did the write is uncommitted, dirty reads are generally a bad idea as you may act based on something that is subsequently thrown away. Only useful use I've found for them: emulating sequences on a DB without them.
This is a good article that outlines some of the pros of the Read Uncommitted Level. When speed is pertinent and you need to run multiple transactions quickly, such as an E-commerce store, Read Uncommitted allows you to immediately execute the next transaction, without waiting for the first to complete execution.
http://codingsight.com/understanding-dirty-read-problem-sql-...
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#6Since the transaction that did the write is uncommitted, dirty reads are generally a bad idea as you may act based on something that is subsequently thrown away. Only useful use I've found for them: emulating sequences on a DB without them.
Could another use be to debug something that is happening inside a transaction?
https://stackoverflow.com/questions/2471055/why-use-a-read-u...
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#7Like everything, it depends on the use case. Public facing financial transactions have different objectives than an RSS feed of LoL Cat pictures.
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#8Like everything, it depends on the use case. Public facing financial transactions have different objectives than an RSS feed of LoL Cat pictures.
Fair enough. In my case I am making recommendations to clients, so it sounds like it is best to take it on a case by case basis. The majority of the literature seems to be about avoiding Dirty Reads, but there are some beneficial uses.
Re: Ask HN: Dirty Reads for Databases: Good Thing or Bad?
#9Like everything, it depends on the use case. Public facing financial transactions have different objectives than an RSS feed of LoL Cat pictures.
Fair enough. In my case I am making recommendations to clients, so it sounds like it is best to take it on a case by case basis. The majority of the literature seems to be about avoiding Dirty Reads, but there are some beneficial uses.
[deleted]