Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.
Sign up to join this community
On the Wikipedia page for Isolation (database systems), when explaining dirty reads, it says:
The only thing that may be prevented in the READ UNCOMMITTED isolation level is updates appearing out of order in the results; that is, earlier updates will always appear in a result set before later updates.
I am confused about in which case updates would appear out of order in the results. I think it is impossible and not what READ UNCOMMITTED isolation level avoids?
That entry is poorly-worded, so I don't blame you for getting confused by it.
The author(s) appear to be trying to make the point that even when dirty reads are allowed, it is impossible to encounter changes made by a later update before seeing changes made by an earlier update.
In other words, a 'dirty read' will always include all changes (committed or not) up that point in time.
It seems to be a way to stress a perceived difference compared with non-repeatable reads, as the preceding sentence mentions:
Dirty reads work similarly to non-repeatable reads; however, the second transaction would not need to be committed for the first query to return a different result.
No such distinction appears in the original definitions as I understand them, so it would be better if the part you refer to were removed.
Note that an implementation of read uncommitted isolation is not required to experience dirty reads, just that it may. Several popular products provide a read uncommitted isolation level that delivers a much higher degree of isolation and protection from so-called read phenomena. This is explicitly allowed by the SQL Standard.
