Что такое Read uncommitted?

Уровень изоляции Read Uncommitted (Чтение незафиксированных данных)

Read Uncommitted — это самый низкий уровень изоляции транзакций в системах управления базами данных (СУБД), таких как SQLite, PostgreSQL, MySQL и других, которые могут использоваться в Android-приложениях. На этом уровне одна транзакция может видеть незафиксированные (неподтверждённые) изменения другой параллельной транзакции.

Ключевая проблема: "Грязное чтение" (Dirty Read)

Основная характеристика этого уровня — допущение грязного чтения. Это означает, что транзакция может прочитать данные, которые были изменены другой транзакцией, но ещё не зафиксированы. Если та транзакция будет откатана (rollback), первая транзакция будет работать с данными, которые никогда по факту не существовали в согласованном состоянии базы.

Практический пример и код

Представим простой случай в контексте Android с Room Persistence Library:

// Допустим, у нас есть две параллельные транзакции, выполняющиеся в разных потоках.

// ТРАНЗАКЦИЯ 1 (Обновляет баланс пользователя)
database.runInTransaction {
    // Шаг A1: Увеличиваем баланс на 100 (но НЕ фиксируем сразу)
    val user = dao.getUser(1)
    user.balance += 100
    dao.updateUser(user) // Изменение записано в БД, но транзакция открыта!

    // Здесь происходит задержка или сложная операция...
    // Пока транзакция не завершена, её изменения ВИДНЫ транзакции 2.
}

// ТРАНЗАКЦИЯ 2 (Читает баланс, уровень изоляции Read Uncommitted)
fun transaction2() {
    // Шаг B1: Чтение происходит ПЕРЕД фиксацией Транзакции 1
    val currentBalance = dao.getUserBalance(1) // Может прочитать значение +100!

    // Допустим, на шаге A2 в Транзакции 1 произошла ошибка и она откатилась (rollback).
    // Тогда баланс пользователя останется старым. Но Транзакция 2 уже считала
    // несуществующее значение и, возможно, приняла на его основе некорректное решение
    // (например, разрешила вывод средств). Это и есть "грязное чтение".
}

Почему Read Uncommitted редко используется в Android?

1. Нарушение целостности данных: Как видно из примера, это может привести к серьёзным логическим ошибкам в приложении, когда бизнес-логика опирается на несуществующие данные.
2. Уровни изоляции в SQLite: По умолчанию SQLite (на которой часто работает Room) использует уровень изоляции Serializable в режиме WAL (Write-Ahead Logging) или Read Committed в режиме журнала отката. Явно установить READ UNCOMMITTED в Room или SQLite на Android не представляется стандартным способом. Он существует скорее как теоретическая концепция в стандарте SQL.
3. Производительность vs. Корректность: Этот уровень обеспечивает максимальную производительность (нет блокировок на чтение), но ценой потенциальной порчи данных. Для мобильных приложений корректность данных обычно критичнее.

Сравнение с другими уровнями изоляции

В стандарте SQL определены четыре уровня (от низкого к высокому):

• Read Uncommitted: Возможны грязные чтения, неповторяющиеся чтения, фантомные чтения.
• Read Committed: Исключает грязные чтения, но возможны неповторяющиеся и фантомные чтения.
• Repeatable Read: Исключает грязные и неповторяющиеся чтения, возможны фантомные чтения.
• Serializable: Полная изоляция, исключаются все аномалии.

Итог для Android-разработчика

В реальной Android-разработке с Room, SQLite или Realm вы вряд ли будете явно работать с READ UNCOMMITTED. Однако понимание этой концепции и проблемы грязного чтения крайне важно, потому что:

• Это базовая теория транзакций, которая поможет на собеседовании.
• Вы будете лучше понимать, почему по умолчанию транзакции ведут себя определённым образом.
• При проектировании архитектуры данных вы сможете осознанно выбирать места, где необходимы явные транзакции с подходящим уровнем гарантий, используя механизмы, предоставляемые Room (например, @Transaction, runInTransaction).
• Это знание пригодится при работе с другими базами данных или серверными частями приложения, где настройка уровня изоляции — обычная практика.

Таким образом, Read Uncommitted — это важная теоретическая концепция, иллюстрирующая базовые проблемы параллельного доступа к данным и компромисс между производительностью и целостностью. В Android-экосистеме её прямое использование нетипично, но понимание принципа необходимо для грамотной работы с персистентностью.