Статья на википедии имеет более глубокие исторические корни, она не про то какие сейчас есть клевые СУБД, а о том как они развивались. Т.е. когда-то давно-давно, были простейшие СУБД без транзакций, без изолированности и пользователи при их эксплуатации сталкивались с определенными ошибками: кто-то увидел чужие данные которых не было, кто-увидел фантомные данные, которых больше нет и так далее, в ответ на эти проблемы появлялись более строгие уровни изоляции данных. При этом есть дилемма: чем выше уровень изоляции - тем ниже производительность системы. Т.е. это статья больше о теории хранения данных с совместным доступом, например, с какими проблемами вы столкнетесь, если захотите написать свой транзакционный движок.
Теперь про потерянное обновление, есть таблица Counter с одной строкой и полем count = 0.
Транзакция №1
UPDATE counter SET count = count + 10;
что в это время делает движок:
1. читает текущее значение count равное 0
2. прибавляет к нему 10
3. но транзакция еще не завершена, и новое значение 10 просто держится в памяти
В это время стартует Транзакция №2 с тем же самым запросом
UPDATE counter SET count = count + 10;
что делает движок? То же самое что и в первый раз:
1. читает текущее значение count равное 0, потому что первая транзакция еще не завершена, и вторая не видит её результатов <- это и есть уровень изоляции, мы или видим данные в чужой транзакции или нет.
2. прибавляет к нему 10
3. завершаем Транзакцию №2 и на диск сохраняется count равное 10.
После этого подоспела и первая транзакция, она тоже готова сохранить своё вычисленное значение count равное 10 и на диск снова пишется 10, а не 20, как мы ожидали.
Современные промышленные СУБД такой трюк провести не дадут (строки на время update будут заблокированы), а вот студент, который пишет программу для курсовой работы, может допустить такую не очевидную ошибку.
