Comments 12
по-моему такие проблемы решаются с помощью настройки уровня изолированности транзакций, а не лишними столбцами в таблицах
Не совсем, уровни изоляции про другое. Смотри. У тебя есть задача по резервированию товаров заказа, причем работать приходится с разными магазинами, т.к. ты интегратор. Ты можешь сделать так, что бы каждый товар резервировался по отдельности.
Что получаешь в этом случае? Допустим, что резервирование чего-то не удалось. Тогда ты сможешь спокойно отследить что именно нужно отменить, на каком этапе процесс резервирования заказа остановился. Или наоборот, предложить пользователю изменить заказ, например отправив письмо или как-то еще уведомив, что данный товар не удалось для него найти.
Даже если в процессе резервирования что-то упадет, то ты о том факте, что уже пытался - будешь знать. Ведь можно в процессе сброса задачи установить флаг "пытался, но что-то не получилось".
Тут не просто блокировки, а полный контроль процесса.
О чем вообще речь? Что это за субд? "Есть два потока и таблица1 с сущностями, так же есть таблица2, в которой могут быть сущности с ссылками на первую."
Батенька. Вы с термтнологией для начала сами разберитесь. Прежде чем выдавать оценочное суждение о других. Что такое в вашем пониманит "таблица" и что такое "сущность".. если в термтнах стандартной ER модели (судя по использованию acid принципа для реляционных субд) то сущность это и есть то, что вы называете "таблицей"... хотя правильнее называть: "отношение". под вашей же "сущностью" (что бы это ни значило) подразумевается, скорее всего кортеж.
редис и прочие ему подобные программы не являются субд в классическом понимании этого термина. и по этому к ним пишутся подобные костыли.
Что же будет дальше?
чисто формально, в заголовке есть утверждение "Что означает I в ACID и как это можно использовать", в тексте статьи это не раскрывается, как и фактически не употребляется заявленный в заголовке термин (ACID). Даже если это вам кажется очевидным, что заявляется в заголовке обязано раскрываться в тексте статьи, хотя бы ссылкой на статью в Википедии.
Мне кажется ACID - это более фундаментальные вещи. В статье описана логическая блокировка записей. Например порция данных, которую мы взяли в обработку.
Но даже если продолжать в том же духе - как всегда "все зависит от".
В Oracle и MS SQL я мог, используя Serializable или Repeatable read, сделать обновление логического флага/статуса. А вот в MySQL такой финт не прошел, база начинала выдавать разные записи, и вроде даже дубли. Я дальше не стал раскапывать, так как в том проекте уже была еще одна внешняя блокировка, кстати в виде таблицы в том же MySQL. А вот когда я эту таблицу заменил на RedLock на основе Redis - проекту в целом похорошело.
Использовать запись в реляционную базу только для установки лока ?
Я не спец по оптимизации, но тот же Redis будет работать куда быстрее и лучше (установка лока и его максимального времени существования)
И если вам нужно отслеживать процесс, можете выкинуть тот же exception и уже после этого отправлять запрос в основную БД о.о
Речь в статье не просто про лок, а про контроль целостности.
В статье уже написано, что для задач, которые выполняются быстрее, чем 0.5 мс такой лок не имеет особо смысла, если только не является важным контроль факта выполнения задачи.
Использовать редис или любой другой инструмент только потому, что хочется - не является инженерныv подходом, а любительством. Вам действительно нужен инструмент, который при падении теряет все ваши данные? Редис же в памяти работает. А ваша БД - она даже если упадет, целостность гарантирует.
deleted
1.Есть ряд обучающих материалов по изоляции транзакций за авторством Е.Рогова, например, https://habr.com/ru/company/postgrespro/blog/442804/.
2.В этих материалах автор предостерегает от ошибок связанных, с тем что в одном запросе идет проверка, а в другом запросе по результатам проверки, осуществляются действия с этой записью. Автор считает такой подход антипаттерном, т.к. между двумя этими запросами в параллельном потоке эта запись может быть изменена.
Оно действительно так, если у вас долгие транзакции и вы пытаетесь проводить какие-то сложные операции.
Если транзакция заканчивается сразу после этих изменений, то другие транзакции это увидят и будут выполнять свои запросы соответствующим образом. Не бывает так, что запрос начал выполняться с одними данными, а закончил с другими, тогда пример с вставкой и удалением не работал бы, а должен. Атомарность где?
Опять же, прошу в гитхаб и попробуй сломать пример. Покажи какую конфигурацию нужно сделать или манипуляции произвести, что бы тот код перестал работать (при условии, что после апдейта транзакция должна быть закрыта сразу). Нужно что бы счетчик параллельных блокировок хотя бы раз сообщил об ошибке.
Что означает I в ACID и как это можно использовать