Дневник капитана, красивая дата 05*05=25
➖Кислотные транзакции➖

Захотелось рассказать про темы, которые обычно не часто обсуждаются в среде 1Сников: транзакции, блокировки и связанные темы. В первом посте расскажу о самих транзакциях.

Думаю, что такое транзакция знает большинство. Ну, напомню кратко на всякий. Это такие операции с базой данных (в первую очередь), которые выполняются либо все, либо ни одной (при какой-либо проблеме, ошибке). Отдельно часть операций из транзакции выполнять не допустимо.

Еще в 1970-х годах был выдвинут набор требований к транзакциям, который называется ACID 🧪:
Atomicity - атомарность
Consistency - согласованность
Isolation - изоляция
Durability – устойчивость
Разберем каждую букву подробнее.

⚛️ Атомарность
Этот принцип как раз говорит о том, что транзакция неделимая, она может быть зафиксирована либо вся, либо ни одна ее часть. В общем-то, тривиальное требование для транзакции, верно? Да, в обычном случае так оно и есть. Интересней становится, когда у вас сложная система, состоящая из разрозненных узлов. Потом разберем в отдельном посте, как это решается в микросервисной архитектуре, и что можно сделать в 1С.

🤝 Согласованность
Транзакция должна приводить систему из одного консистентного состояние в другое. Это могут быть такие более низкоуровневые требования, как уникальность ключей, отсутствие битых ссылок и т.д. А могут быть и требования, наложенные бизнес-логикой: если деньги с одного счета ушли, то на другой пришли; на складе не может быть отрицательное количество товара и подобное.

Если за первый набор требований отвечает сама СУБД, то о вторых нужно озаботиться разработчикам. Это решается проверками, которые происходят перед или во время транзакции записи данных. Однако интересная ситуация может произойти, когда между проверкой и выполнением операции влезет другой процесс и нарушит логику. Это дело для блокировок, о которых расскажу в другом посте.

🔒 Изоляция
Транзакции должны быть изолированы друг от друга, никак одна начавшаяся или совершенная транзакция не должна "заафектить" открытую другую. Это требование оказалось слишком жестким, поэтому чистая изоляция сейчас почти не используется. Была выделены разные уровни изолированности транзакций, которые в разной степени смягчают это требование. И это тема для отдельного поста.

💪 Устойчивость
Это значит то, что если транзакция завершена, то разные внешние и низкоуровненые факторы не должны удалить изменения, сделанные ею. Т.е. если транзакцию зафиксировали, а через секунду свет вырубили, то после включения ничего не должно потеряться. Здесь можно выдохнуть, нас, как разработчиков логики, это не касается. Это уже все должно работать на уровне СУБД и железок. Но бэкапы все равно делать надо!

Если совсем кратко, то на этом все, дальше я уже напишу отдельные посты по упомянутым темам.