Допустимо ли создание вложенных транзакций

Вложенные транзакции в Go (с использованием context.Context)

В стандартной библиотеке Go нет прямого механизма вложенных транзакций как в некоторых других языках (например, SAVEPOINT в SQL). Однако концепция "вложенности" может быть реализована через управление контекстом (context.Context) и композицию действий. Рассмотрим подходы и ограничения.

Отсутствие вложенности на уровне драйвера базы данных

Большинство драйверов баз данных (например, database/sql с PostgreSQL/MySQL) не поддерживают вложенные транзакции напрямую. Транзакция — это единичная операция на уровне соединения с БД.

// Пример обычной транзакции
db, err := sql.Open("postgres", "connection_string")
tx, err := db.Begin() // Начало транзакции
// Невозможно вызвать tx.Begin() внутри этой транзакции

Эмуляция через Savepoints (если поддерживается БД)

Для баз данных, поддерживающих SAVEPOINT (PostgreSQL, некоторые версии MySQL), можно эмулировать вложенность:

func nestedOperation(ctx context.Context, tx *sql.Tx) error {
    // Создание точки сохранения
    _, err := tx.Exec("SAVEPOINT nested_savepoint")
    if err != nil {
        return err
    }
    
    // Выполнение операций
    _, err = tx.Exec("INSERT INTO table1 ...")
    if err != nil {
        // Откат до точки сохранения
        tx.Exec("ROLLBACK TO nested_savepoint")
        return err
    }
    
    // Освобождение точки сохранения
    _, err = tx.Exec("RELEASE SAVEPOINT nested_savepoint")
    return err
}

Основной подход: композиция через context.Context

На практике "вложенные транзакции" в Go организуются через передачу контекста и делегирование управления родительской транзакции:

func parentOperation(ctx context.Context, db *sql.DB) error {
    // Начинаем родительскую транзакцию
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    
    // Выполняем "вложенные" операции, передавая ту же транзакцию
    err = childOperation1(ctx, tx)
    if err != nil {
        tx.Rollback()
        return err
    }
    
    err = childOperation2(ctx, tx)
    if err != nil {
        tx.Rollback()
        return err
    }
    
    return tx.Commit()
}

func childOperation1(ctx context.Context, tx *sql.Tx) error {
    // Работаем с той же транзакцией
    _, err := tx.ExecContext(ctx, "INSERT ...")
    return err
}

Ключевые принципы:

1. Единая транзакция на уровне соединения — все "вложенные" операции работают с одним объектом *sql.Tx.
2. Контекст для управления — context.Context позволяет передавать параметры, управлять таймаутами и отменой.
3. Ручное управление откатами — при ошибке в любой "вложенной" операции требуется откат всей родительской транзакции.
4. Отсутствие автономности — нельзя независимо коммитить/откатывать часть транзакции без влияния на всю операцию (кроме SAVEPOINT).

Пример с промежуточным откатом:

func processWithNestedLogic(ctx context.Context, tx *sql.Tx) error {
    // Шаг 1
    if err := step1(ctx, tx); err != nil {
        return err // Транзакция будет откатана на уровне родителя
    }
    
    // Шаг 2 с возможностью "локального отката" через savepoint
    if err := step2WithSavepoint(ctx, tx); err != nil {
        // Здесь мы уже откатились до savepoint, но транзакция ещё активна
        return err
    }
    
    return nil
}

Ограничения и рекомендации:

• Нет транзакций внутри транзакций — в Go это архитектурно не поддерживается.
• Логическая вложенность вместо механической — организуйте код через функции, принимающие *sql.Tx.
• Использование BeginTx() — для контроля изоляции и таймаутов через контекст.
• Опасность deadlock — при сложной "вложенной" логике увеличивается риск блокировок.

Альтернативы для сложных сценариев:

1. Организация через сервисы — каждый сервис получает транзакцию из внешнего слоя.
2. Паттерн Unit of Work — сбор всех операций перед единым коммитом.
3. Транзакционные скрипты — выполнение последовательности SQL в одной транзакции.

Вывод: Создание механических вложенных транзакций в Go недопустимо на уровне API драйверов, но логическая вложенность через композицию функций и контекст является стандартным и рекомендованным подходом. Используйте SAVEPOINT при необходимости частичных откатов, если ваша база данных поддерживает эту функцию.