Транзакции — db.Transaction, вложенность, SavePoint и уровни изоляции в GORM

Канон к этому моменту умеет почти всё: модели и связи, Create с каскадом, чтение жадной загрузкой — и всё это работает при условии, что каждый запрос самодостаточен. Но настоящий сценарий — не запрос, а маршрут из нескольких шагов. Возьмём перенос задачи из списка «Дом» в «Работа»: Update задачи со сменой todo_list_id, затем комментарий «Перенесено в «Работа» как журнал, затем, возможно, правка служебных полей списков. Каждая команда GORM выполняет честно и последовательно — и вот в чём проблема: между шагами база переживает состояния, которых не должно существовать. Задача уже переехала, а журнал о переносе ещё не создан; упади второй шаг — состояние зависнет навсегда, потому что ни один механизм сам его не починит: база считает, что всё хорошо, ведь каждый оператор по отдельности прошёл успешно. gorm транзакции существуют ровно для этого: собрать шаги в атомарный маршрут, для читателя которого есть только «до» и «после» и нет промежуточных полуфабрикатов. Атомарность — это свойство единицы работы, а не отдельных операторов; СУБД умеет её обеспечивать, если ей об этом сказать словом BEGIN и закончить словом COMMIT или ROLLBACK. Кто набирает в поиске transaction go, ищет ту же вещь: begin вокруг нескольких операций и гарантированный откат, если что-то пошло не так. Дальше разберём всю лестницу управления транзакциями в GORM: от авто-обёртки одиночных команд — до вложенных блоков, SavePoint и уровней изоляции.

Разберём обёртку по исходникам — она проще, чем кажется. Реализация обоих колбэков живёт в callbacks/transaction.go, а в callbacks/callbacks.go у трёх конвейеров записи — create, update, delete — первым зарегистрирован колбэк gorm:begin_transaction, а последним — gorm:commit_or_rollback_transaction; оба вешаются с условием Match(enableTransaction), где enableTransaction — это просто !db.SkipDefaultTransaction. У конвейеров чтения — gorm:query и gorm:preload из четырнадцатого урока — таких колбэков нет: SELECT-ы в авто-транзакции не едут. Начало: BeginTransaction проверяет db.Error (запрос уже битый — открывать транзакцию поздно), зовёт db.Begin(), подменяет Statement.ConnPool на соединение транзакции и помечает факт InstanceSet("gorm:started_transaction", true). Конец: CommitOrRollbackTransaction смотрит на метку и решает — db.Error != nil значит Rollback, иначе Commit, после чего возвращает ConnPool обратно. Отсюда правило: одиночная запись атомарна по умолчанию, но три последовательных записи — это три отдельных транзакции, а не одна. Теперь SkipDefaultTransaction — углубим то, что пятый урок обронил мимоходом. Комментарий в gorm.go говорит прямо: single create, update, delete operations run in transactions by default to ensure database data integrity. Отключение — глобально в gorm.Open через &gorm.Config{SkipDefaultTransaction: true} или точечно через db.Session(&Session{SkipDefaultTransaction: true}) — снимает обёртку и даёт, по доке, about 30%+ performance improvement. Отключать честно тогда, когда каждая запись — одна команда к одной таблице и атомарна сама по себе, а каскадов и хуков, которым нужна общая судьба, нет; помните и про батч-вставку из пятого урока — там обёртка тоже исчезнет, потому и совет был «подумайте дважды». Последний нюанс: внутри уже открытой транзакции авто-обёртка не сработает второй раз — BeginTransaction вызовет db.Begin(), чей ConnPool уже *sql.Tx, получит ErrInvalidTransaction и молча его погасит: операция спокойно едет во внешней транзакции.

Для многошаговой записи у GORM есть блок: db.Transaction(func(tx gorm.DB) error { ... }). Дока описывает его формулой: возвращаете ошибку — откат, nil — коммит; комментарии в доковском примере говорят то же самое — return any error will rollback и return nil will commit the whole transaction. В исходниках finisher_api.go метод документирован как start a transaction as a block — «транзакция как блок», и это точнее всего: тело замыкания и есть ваш блок. Механика на успех: db.Begin(opts...) открывает транзакцию, fc(tx) исполняется, при err == nil сбрасывается флаг panicked и возвращается tx.Commit().Error — то есть ошибка самого COMMIT тоже приедет наружу, проверяйте возвращаемое значение. Механика на провал важнее: deferred-функция откатывает транзакцию, если err != nil ИЛИ panicked — да, паника внутри fc тоже откатывает блок (rollback выполняется на этапе размотки стека), но сама паника не гасится и улетает вызывающему, как и без GORM. Главное правило блока сформулировано в доке прямо: do some database operations in the transaction (use 'tx' from this point, not 'db'). tx — это тот же gorm.DB, у которого ConnPool подменён на *sql.Tx открытой транзакции; db — прежний пул с autocommit. Операция через db внутри блока выполнится немедленно и останется в базе, даже когда блок откатится, — самая тихая ошибка из возможных. Возвращаемое значение db.Transaction — либо ваша ошибка из fc, либо ошибка Commit; Count и RowsAffected здесь не нужны: блок либо сработал целиком, либо не сработал вообще.

А что, если вызвать db.Transaction внутри db.Transaction? Ничего не сломается — GORM поддерживает вложенные блоки, и та же самая функция Transaction разрулит это сама. Детектор примитивен и надёжен: в начале метода Statement.ConnPool проверяется на TxCommitter — интерфейс с Commit и Rollback; внутри открытой транзакции ConnPool — это *sql.Tx, то есть TxCommitter, и метод уходит в ветку nested transaction. Дальше, если конфиг DisableNestedTransaction не задан, GORM ставит savepoint за вас: spID := new(maphash.Hash).Sum64() — случайное 64-битное число (не счётчик, на конкретное имя рассчитывать нельзя), затем db.SavePoint(fmt.Sprintf("sp%d", spID)), а deferred-функция при panicked || err != nil делает db.RollbackTo с тем же именем. Тело внутреннего блока исполняется на db.Session(&Session{NewDB: db.clone == 1}) — свежем инстансе с чистым Statement, чтобы цепочки Where не протекали между уровнями. Семантика ровно из доки: вы можете откатить подмножество операций внутри большого блока — rollback a subset of operations performed within the scope of a larger transaction. В доковском примере user1 создаётся внешним блоком, первый внутренний блок с user2 возвращает errors.New("rollback user2"), второй внутренний блок с user3 возвращает nil — финальный комментарий доки: Commit user1, user3. Заметьте: ошибка внутреннего блока возвращается из tx.Transaction как обычный error — что с ней делать, решаете вы: залогировать и продолжить (тогда внешний COMMIT пройдёт, минус откачанная часть) или пробросить дальше (тогда deferred внешнего блока откатит всё, включая прошедшие шаги). А DisableNestedTransaction: true меняет поведение: savepoint не ставится, внутреннее тело едет на той же транзакции, и его ошибка, выйдя наружу, откатывает уже весь внешний блок.

SavePoint можно и нужно уметь ставить руками — это оператор СУБД, аккуратно прокинутый через API. Дока: GORM provides SavePoint, RollbackTo to save points and roll back to a savepoint. Методы живут на *gorm.DB рядом с Commit и Rollback: tx.SavePoint("sp1") уезжает как SAVEPOINT sp1, tx.RollbackTo("sp1") — как ROLLBACK TO SAVEPOINT sp1, а SQL для диалекта строит dialector. За кулисами — интерфейс SavePointerDialectorInterface с двумя методами SavePoint(tx, name) и RollbackTo(tx, name): драйверы MySQL, Postgres и SQLite его реализуют, а что-то без поддержки вернёт ErrUnsupportedDriver. Три факта, которые сберегут нервы. Первый: savepoint существует только внутри открытой транзакции — голый db.SavePoint на autocommit-соединении не оставит после себя живой точки сохранения; ставьте их на tx. Второй: ROLLBACK TO SAVEPOINT откатывает работу после точки и уничтожает более поздние savepoints, но не закрывает саму транзакцию — COMMIT после него легален и зафиксирует всё, что выжило. Третий, для любителей PrepareStmt: в исходниках методы SavePoint и RollbackTo временно подменяют PreparedStmtTX на сырой Tx и восстанавливают обратно — с комментарием, что savepoint-команды несовместимы с prepared statements, MySQL 8.0 на это явно ругается. GORM делает грязную работу за вас, но знайте: с включённым PrepareStmt каждое SavePoint и RollbackTo теряет кэш подготовленных выражений этой транзакции. Доковский пример минимален: tx := db.Begin(); Create user1; tx.SavePoint("sp1"); Create user2; tx.RollbackTo("sp1") — Rollback user2; tx.Commit() — Commit user1. Именно его повторим на каноне ниже.

Замыкание — не единственный стиль. GORM поддерживает вызов команд управления транзакцией напрямую: tx := db.Begin(), операции на tx, затем tx.Rollback() или tx.Commit(). Дока показывает аккуратный пример CreateAnimals, и его стоит разобрать построчно, потому что он собирает все правила сразу. Первое: db.Begin() возвращает DB — конвейер, у которого ConnPool подменён на транзакцию; ошибка старта живёт в tx.Error, и её проверяют сразу после Begin: if err := tx.Error; err != nil { return err }. Внутри Begin используется BeginTx контекста соединения — интерфейсы TxBeginner и ConnPoolBeginner; что-то третье даст ErrInvalidTransaction, а настройка DefaultTransactionTimeout, если она задана и у контекста нет дедлайна, оборачивает контекст в context.WithTimeout. Второе: каждая ошибка операции — tx.Rollback() и возврат; забытый Commit после Begin оставляет соединение в висящей транзакции, и пул медленно истощается. Третье: defer с recover — если тело паникует, tx.Rollback() выполняется на размотке: ровно то, что db.Transaction делает под капотом в своём флаге panicked. Четвёртое: финал — return tx.Commit().Error, ошибка коммита возвращается вызывающему. Ориентиры выбора: замыкание Transaction — стиль по умолчанию, компактный и паникобезопасный; ручной Begin и Commit берут тогда, когда транзакцию не натянуть на одну функцию — ранние возвраты из глубины, передача tx между функциями, логирование промежуточных шагов. И предупреждение из исходников: Commit и Rollback на gorm.DB без транзакции дают ErrInvalidTransaction — оно попадёт в Error результата, а не в панику, так что проверяйте результат явно.

Уровень изоляции — это ответ СУБД на вопрос, какие чужие недоделанные изменения вы можете увидеть. Классические аномалии: грязное чтение (dirty read) — данные чужой незакоммиченной транзакции; неповторяющееся чтение (non-repeatable read) — повторный SELECT видит другой закоммиченный UPDATE той же строки; фантомы (phantom) — повторный запрос видит новые подходящие строки. GORM не изобретает свою лестницу: clause.Isolation в ядре нет — слово Isolation в исходниках GORM не встречается вовсе — а изоляция задаётся стандартным *sql.TxOptions из database/sql, который Transaction и Begin принимают вариадиком: db.Transaction(fc, &sql.TxOptions{Isolation: sql.LevelSerializable}) или db.Begin(&sql.TxOptions{Isolation: sql.LevelRepeatableRead}). Набор констант database/sql: LevelDefault — не трогать, работает серверный уровень; далее LevelReadUncommitted, LevelReadCommitted, LevelRepeatableRead, LevelWriteCommitted, LevelSerializable, LevelLinearizable. Что с ними сделает драйвер — вопрос уже драйвера. go-sql-driver/mysql перед BEGIN выполняет SET TRANSACTION ISOLATION LEVEL: карта уровней знает четыре классических — READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE; остальное даёт «mysql: unsupported isolation level». lib/pq строит BEGIN с хвостом ISOLATION LEVEL READ COMMITTED или другим из тех же четырёх. Дефолты помните всегда: PostgreSQL — READ COMMITTED, и его READ UNCOMMITTED ведёт себя как READ COMMITTED; MySQL InnoDB — REPEATABLE READ. Практика: для обычного CRUD дефолт честен; REPEATABLE READ берут для отчётов, где повторные SELECT обязаны видеть один и тот же снимок; SERIALIZABLE — для денег и инвариантов, помня, что конфликтующие транзакции получают ошибку сериализации и требуют повтора. Уровень — свойство транзакции, а не сессии навсегда: в MySQL SET TRANSACTION ISOLATION LEVEL без SESSION и GLOBAL действует на следующую транзакцию соединения — потому драйвер и ставит его прямо перед вашим BEGIN.

Лестница транзакций пройдена целиком: авто-обёртка одиночных команд, блок db.Transaction с ошибкой вместо COMMIT, вложенные вызовы, которые сами превращаются в SavePoint, ручной Begin и Commit и уровни изоляции через sql.TxOptions. Полезно вернуться и перечитать свой код: многошаговая запись без блока — самое частое место тихих полуфабрикатов, а m2m-канон из тринадцатого урока с его тегами — готовый кандидат на блок: назначение нескольких тегов задаче хочется выполнять целиком. Preload внутри блока видит ровно те данные, что и его владелец, — gorm:query и gorm:preload едут по ConnPool той же транзакции, о чём четырнадцатый урок обещал в финале. Карта курса из 25 уроков — на странице курса. Дальше — периферия записи: Шестнадцатый урок «Хуки жизненного цикла» покажет BeforeCreate и AfterUpdate, валидацию в хуках и одну важную связку с сегодняшней темой: ошибка, возвращённая из хука, попадает в db.Error, а значит — gorm:commit_or_rollback_transaction откатит авто-транзакцию: хук — ещё один рычаг атомарности, теперь вы знаете, куда он врезается. Домашка ниже собирает весь урок в один скрипт.