Что такое транзакция

Mysql в движке InnoDB отвечает требованиям ACID к обработке транзакций (в MyISAM не поддерживается):

• Atomicity - атомарность
• Consistency - согласованность
• Isolation - изолированность
• Durability - надежность

Нашему приложению транзакции могут помочь в обеспечении целостности данных, когда данные меняются несколькими операциями, и в обеспечении изолированности, чтобы конкурентные хиты не читали незакомиченные промежуточные данные.

Вот классический случай, когда проблема может/должна быть решена транзакцией:

При отправке писем методом CEvent::Send файл может быть не отправлен, если в момент выполнения скрипта будет запущен крон, который отправляет письма. Это происходит потому, что в функции /bitrix/modules/main/lib/mail/event.php запись в таблицу b_event происходит до сохранения файла (58 строка и далее по условию).

Старое правило

Ранее, до обновления main 22.200.0, действовало правило:

Такое правило было потому, что Mysql не поддерживает вложенные транзакции. Могла сложиться ситуация, когда конечный сценарий открывает транзакцию, вызываемый API тоже открывает свою транзакцию, в итоге все коммиты и роллбеки перемешиваются непредсказуемым образом.

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

Вложенные транзакции

Для транзакций нужно использовать API драйвера БД \Bitrix\Main\DB\Connection, методы startTransaction(), commitTransaction() и rollbackTransaction().

Если транзакции вложенные, то повторные старты транзакций создают именованные точки сохранения MySQL SAVEPOINT. Промежуточные коммиты ничего не коммитят. Последний закрывающий коммит коммитит все произведенные с начала первой транзакции изменения.

Сложности возникают, если какие-то из вложенных транзакций захотят откатить изменения в своей транзакции. В этом случае мы попадаем в неопределенную ситуацию, т.к. итоговую цель всех изменений знает только конечный сценарий (см. старое правило).

Поэтому мы действуем в парадигме "вложенные роллбеки не поддерживаются" и даем возможность конечному сценарию решить, как поступить правильно. При наступлении события вложенного роллбека происходит частичный откат к соответствующей точке сохранения ROLLBACK TO SAVEPOINT ... и выбрасывается исключение \Bitrix\Main\DB\TransactionException.

Далее возможны три сценария:

• Исключение никто не ловит, скрипт прекращает работу по ошибке, MySQL автоматически откатывает все незакомиченные изменения.
• Исключение обрабатывает вызывающий код, он решает, что внутренние роллбеки для правильной работы не важны, и продолжает работу с последующим коммитом своих изменений.
• Исключение обрабатывает вызывающий код, он решает, что нет смысла продолжать, и откатывает свои изменения. При этом если вызывающий код сам является вложенной транзакцией, то генерируется новое исключение - и так до самого первого уровня в конечном сценарии.

Пример кода:

$conn = \Bitrix\Main\Application::getConnection();

$conn->query("truncate table test");

try
{
	$conn->startTransaction();

	$conn->query("insert into test values (1, 'one')");

	// nested transaction
	$conn->startTransaction();

	$conn->query("insert into test values (2, 'two')");

	if (true)
	{
		$conn->commitTransaction();
	}
	else
	{
		$conn->rollbackTransaction();
	}
	// end of nested transaction

	$conn->commitTransaction();
}
catch(\Bitrix\Main\DB\TransactionException $e)
{
	$conn->rollbackTransaction();
}

Новое правило

В итоге новое правило работы с транзакциями выглядит так:

Не стоит также забывать, что транзакции не должны быть сильно протяженными по времени, иначе можно легко попасть на deadlock транзакций вплоть до полной остановки приложения. Могут наблюдаться бесконечные откаты транзакций, если операция не может быть завершена до прекращения скрипта по тайм-ауту.