Questions about articles on habré and wikipedia about transaction isolation levels - why is it written that way?

Question

SQL

1) wikipedia article:
https://en.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D...
Lost update:
2 requests simultaneously change the value of a field in a row tables
UPDATE tbl1 SET f2=f2+20 WHERE f1=1; UPDATE tbl1 SET f2=f2+25 WHERE f1=1;

As a result, the value of the field f2 upon completion of both transactions may increase not by 45, but by 20 or 25, that is, one of the data-changing transactions will “disappear”.

Question: given that each individual query in ms sql (and I read that not only in it, but in all DBMS that support transactions) is executed in an implicit automatic transaction, then why would a "lost update" suddenly become possible? Those. the second update will not be able to read the value of f2 until the automatic transaction of the first update completes.
Even if we assume that the author wrote the text, assuming the absence of automatic transactions, the following is not clear: since there are definitely automatic transactions in ms sql, why does ms sql explicitly support the read uncommitted isolation level, which protects only from "lost updates"? After all, even without explicit transactions, there must be protection against them, because. do automatic transactions work?
2) an article on Habré:
https://habrahabr.ru/company/infopulse/blog/261097/ - section Lost update - Interpretation No. 2
, he gives a table there in which 2 parallel updates update the same field in the database similar to that as in the wikipedia article. But the author on Habré has both requests enclosed in the BEGIN TRAN transaction; COMMIT TRAN; , but as a result it writes that a "lost update" will happen.
Question: how can a lost update happen if both of its requests are executed each inside their own transaction?

Answer 1

You don't seem to understand the essence of the concept of "transaction". It only means that the logical group of operations will either be completely executed or completely rolled back. What neighboring transactions "see" during the operation of a particular transaction depends on the isolation level. It can be about everything, including the subtotals of an uncommitted transaction, or it can be nothing at all

Answer 2

The Wikipedia article has deeper historical roots, it is not about what cool DBMS are now, but about how they developed. Those. once upon a time, there were the simplest DBMS without transactions, without isolation, and users encountered certain errors during their operation: someone saw other people's data that was not there, someone saw phantom data that no longer exists, and so on, in response stricter levels of data isolation appeared to address these issues. At the same time, there is a dilemma: the higher the isolation level, the lower the system performance. Those. this article is more about the theory of shared data storage, for example, what kind of problems you will face if you want to write your own transactional engine. Now about the lost update, there is a Counter
tablewith one row and field count = 0.
Transaction #1
UPDATE counter SET count = count + 10;
what the engine does at this time:
1. reads the current value of count equal to 0
2. adds 10 to it
3. but the transaction is not completed yet, and the new value 10 is just kept in memory
At this time, Transaction #2 starts with the same
UPDATE request counter SET count = count + 10;
what does the engine do? The same as the first time:
1. reads the current value of count equal to 0, because the first transaction has not yet completed, and the second does not see its results <- this is the isolation level, we either see the data in someone else's transaction or not.
2. adds 10 to it
3. we complete Transaction No. 2 and count equal to 10 is saved to disk.
After that, the first transaction arrived in time, it is also ready to save its calculated count value equal to 10 and 10 is written to disk again, not 20, as we expected.
Modern industrial DBMS will not allow such a trick to be carried out (lines will be blocked for the time of update), but a student who writes a program for term paper can make such an unobvious mistake.