Какие знаешь уровни изоляций?

Уровни изоляции транзакций в Android и SQL

В контексте Android разработки, особенно при работе с базами данных (SQLite через Room или напрямую), вопрос об уровнях изоляции транзакций относится к стандарту SQL и принципам ACID (Atomicity, Consistency, Isolation, Durability). Изоляция гарантирует, что параллельные транзакции не влияют друг на друга некорректно.

Основные уровни изоляции (стандарт ANSI SQL)

Стандарт определяет четыре уровня, регулирующие видимость изменений между параллельными транзакциями:

1. READ UNCOMMITTED (Чтение незафиксированных данных)

    *   Самый низкий уровень. Транзакция может видеть **"грязные" данные (dirty reads)** — изменения из других незавершенных транзакций.
    *   Высокий риск неконсистентности. В Android/SQLite практически не используется.

1. READ COMMITTED (Чтение зафиксированных данных)

    *   Транзакция видит только изменения, которые уже были **зафиксированы (committed)** другими транзакциями.
    *   Исключает `dirty reads`, но допускает **"неповторяемое чтение" (non-repeatable reads)**: если в одной транзакции дважды читать одну строку, между чтениями другая транзакция может изменить и зафиксировать эту строку, и второе чтение получит разные данные.

1. REPEATABLE READ (Повторяемое чтение)

    *   Гарантирует, что данные, прочитанные в начале транзакции, не изменятся другими транзакциями до её завершения. Исключает `dirty reads` и `non-repeatable reads`.
    *   Однако допускает **"фантомное чтение" (phantom reads)**: если выполнить дважды запрос с условием (например, `SELECT * FROM users WHERE age > 18`), между запросами другая транзакция может **добавить (INSERT)** новую строку, удовлетворяющую условию, которая появится при втором запросе.

1. SERIALIZABLE (Сериализуемый)

    *   Самый строгий уровень. Транзакции выполняются так, как если бы они шли строго последовательно, одна за другой.
    *   Исключает все проблемы: `dirty reads`, `non-repeatable reads` и `phantom reads`. Обеспечивает полную изоляцию, но может серьезно снижать производительность из-за блокировок.

Особенности в Android (SQLite)

SQLite поддерживает три уровня изоляции, но его реализация отличается от классической:

// Пример использования транзакций в Room Persistence Library
@Dao
interface UserDao {
    @Transaction // Аннотация для обозначения транзакционного метода
    fun updateComplexUserData(user: User, profile: Profile) {
        updateUser(user)
        updateProfile(profile)
        // Внутри метода Room выполнит операции в одной транзакции
    }

    // Явное управление транзакцией с помощью Database
    fun manualTransaction(db: SupportSQLiteDatabase) {
        db.beginTransaction() // Начало транзакции
        try {
            db.execSQL("UPDATE Users SET name = 'John' WHERE id = 1")
            db.execSQL("INSERT INTO Log (event) VALUES ('update')")
            db.setTransactionSuccessful() // Маркировка как успешной
        } finally {
            db.endTransaction() // Завершение. Если не вызван setTransactionSuccessful, будет rollback.
        }
    }
}

• Деferred (Отложенная): Это дефакто стандартный режим SQLite. Транзакция не приобретает никаких блокировок до первой операции чтения или записи. При первой операции чтения приобретается SHARED LOCK, при первой операции записи — RESERVED LOCK. Это позволяет многим транзакциям читать одновременно, но только одна может писать. В терминах ANSI SQL это похоже на READ COMMITTED или REPEATABLE READ для чтения внутри транзакции, но с особенностями механизма блокировок.
• Immediate (Немедленная): Транзакция сразу пытается приобрести RESERVED LOCK. Если другая транзакция уже имеет RESERVED или EXCLUSIVE LOCK, операция может завершиться ошибкой. Используется для предотвращения конфликтов при параллельных попытках записи.
• Exclusive (Эксклюзивная): Транзакция сразу пытается приобрести EXCLUSIVE LOCK, блокируя базу для всех других операций. Это самый строгий режим, приближенный к SERIALIZABLE.

Практика в Room и рекомендации

• Room автоматически управляет транзакциями для @Insert, @Update, @Delete и аннотированных @Transaction методов, используя механизмы SQLite.
• Для сложных операций всегда используйте @Transaction, чтобы гарантировать атомарность и согласованность.
• Понимание уровней изоляции важно при:

    *   Разработке приложений с высокой параллельной активностью (многопоточный доступ к БД).
    *   Оптимизации производительности и предотвращении **deadlock**.
    *   Обеспечении корректности данных в критических операциях (например, финансовые расчеты).

Таким образом, знание уровней изоляции — это не только теоретическое понимание ACID, но и практическое умение применять транзакции в Android через SQLite и Room, выбирая баланс между надежностью данных и производительностью приложения.