MySQL Forums
Forum List  »  Docs

Ambiguity of documentation on READ UNCOMMITTED with respect to reading your own writes
Posted by: Michael Nelson
Date: August 26, 2018 02:17PM

I would like to suggest that the description of the READ UNCOMMITTED transaction isolation level at https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html is insufficient for determining it's behavior. One particular example is that I cannot determine whether READ UNCOMMITTED has the same behavior as READ COMMITTED with respect to seeing uncommitted changes that were written in the same (current) transaction.

READ UNCOMMITTED is defined in terms of READ COMMITTED, saying it is the same, except that it may see earlier versions of the rows. Part of the definition of READ COMMITTED is that it has consistent reads -- the definition of which includes an exception clause, and it is unclear whether this exception clause also applies to READ UNCOMMITTED.

Here are the specifics of the exception: READ UNCOMMITTED references consistent reads, which are at https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_consistent_read .
Here, it states that "The exception to this rule is that the query sees the changes made by earlier statements within the same transaction. " What is unclear about the documentation of READ UNCOMMITTED is whether this exception to how reads are performed also applies to READ UNCOMMITTED -- will reads of rows that were updated by the currently active transaction be guaranteed to see those modified versions of the row(s)?

Unfortunately, I am not sufficiently familiar with the engine to propose appropriate changes to the documentation to remove this ambiguity. In particular, I don't yet know whether this exception does apply to READ UNCOMMITTED.

Options: ReplyQuote


Subject
Views
Written By
Posted
Ambiguity of documentation on READ UNCOMMITTED with respect to reading your own writes
164
August 26, 2018 02:17PM


Sorry, only registered users may post in this forum.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.