Пасиб ❤️

Привет! Я специально хотел, чтобы именно все, что нужно было в одном месте, так как все это важно. Его можно просто смотреть за несколько дней. Не обязательно сразу :) Я понимаю, что хайпа не будет :) Но, кто осилит, сэкономит несоизмеримо больше времени и на ошибках, так как собирать это все самому очень затратно даже зная, что собираешь.

Да, я знаю про этот варик. Но, видишь, самому сделать один раз - изи пизи. И на разных языках знаем теперь, как сделать. :)

Теперь в случае чего сможешь быстро найти, отмотать и вспомнить :)

Я ее когда прочитал, понял, что она оставляет дохрена открытых вопросов и сложно использовать. Типа вроде понятно, но куча мест, где чуть влево и вправо и хз уже. Но, енивей, очень хороша все равно и видно громадные усилия автора :)

По крайней мере мозги вправляет. После нее фраза "раз мы хреново пишем монолиты, то почему кажется, что сможем хорошо микросервисы писать." Кажется менее смешной и более грустной.

@@grigorii9019 не говори :)

Нет никакой ошибки. Посмотри внимательней, что делает сам паттерн в теоретическом видео и тогда получится понять суть. Я эмулирую запрос, который прилетает с разных сервисов параллельно в конкурентной среде по сети в любой момент времени. И вот так он прилетел. Иначе сделать в консоли это просто нельзя. Так же почитай комменты здесь с рассуждениями. Старайся воспринимать не буквально, а видеть паттерн, который за этим стоит и межсетевое взаимодействие.

Также, посмотри видео про способы работы с бд и concurrency control. Станет более понятно это взаимодействие.

@@dev_pushkin пересмотрел блок из предыдущего видео на 15-й минуте. В принципе, пойнт прежний. Тут не важно, что это с эмуляция запроса с двух серверов. Вы даже если с одного сервиса последовательно такой запрос пришлете, то в итоге будет 1507. Во второй транзакции же даже не читается то, что в изменяемом поле может лежать. Туда просто сеттается новое значение.

Посмотри очень внимательно, что там происходит. Нарисуй на бумажке. Мы читаем из одного сервиса значение и из другого то же значение (пишешь не читаем, что не так). Изоляция у обоих Read Committed. Выполняем какую-то бизнес логику приложения - вычисляем, что нужно старую сумму взять, добавить к ней новое значение и записать в бд. Это происходит конкурентно в каждом из двух сервисов. Изоляция нас не спасает и мы успешно пишем эти значения. Это и есть Lost Update. Уровни изоляции выше могут помочь в таком случае, но не всегда (как мы уже обсуждали в комментах тут). Тут ошибок никаких нет. Есть просто недопонимание работы механизма. Ты, по сути, его и описываешь, говоря, что это не он, используя некое свое понимание его работы. Как ее избежать, я говорю в тех видео, которые выше привел. balance + 7 там тоже есть, но и он не всегда может помочь - это зависит от условия задачи. Посмотри внимательно видео последнее и еще раз продумай ПАТТЕРН работы Lost Update и у тебя сложится картинка. Уже десятки раз обсудили все. Паттерн - мы перезаписываем данные безусловно в разных потоках (транзакция, запрос от сервиса и тд), тем или иным способом, по тем или иным причинам (ошибка в логике, вид и форма задачи и тд), затирая предыдущие данные.

Надеюсь, я тебе помог. Если все еще никак - постарайся больше инфы собрать самостоятельно. Понять, как паттерн работает. Посмотреть примеры другие в статьях.

Привет. В видео не только их четыре, а много других. Про лост апдейт - там тоже есть описание, когда можно защититься. В видео по практике мы пытаемся проверить это. В целом, эта аномалия может иметь разные формы и не всегда изоляция защитит. В последнем видео про concurrency control есть и другие способы решения этой проблемы. Думаю, тебе оно может тоже понравиться!

@@dev_pushkin Гуд, спасибо за оперативный ответ))

Привет. Это норм в пг. Так и будет. Он обеспечивает авто локи. Тебе надо глянуть видос с практикой про уровни изоляции транзакций - там делаем как раз это. Тут смысл не в блокировках или их отсутствии, а в аномалии - последние данные будут из второго запроса. У первого затрутся. Потом мы говорим, как сделать так, чтобы lost update избежать.

Пг хоть и подождет, но запишет новые данные из второго запроса, забыв, что было до этого.

Как раз такое поведение поможет тебе при использовании атомарных апдейтов, в которые мы добавим условия дополнительно для гарантий, если нужно.

​@@dev_pushkin Привет, спасибо за ответ! Вот как раз тоже думал об этом, получается, что хоть транзакции и выполнялись параллельно до лока, та, которая первая возьмет лок закоммитится первой, а другая второй. Получается этакое почти последовательное выполнение. Но раз они выполнялись, можно сказать, последовательно, то можно ли это считать за lost update? Казалось, что lost update - это когда мы потеряли обновление в процессе транзакции, т.к. если бы не было лока, то первая транзакция обновила бы данные, например, записав 200, а вторая, в тот момент, когда первая еще не закончилась, записала бы 300. Тогда, после обновления второй транзакции, первая транзакция бы у себя оперировала значением 300, а не 200, как казалось. Она бы могла еще что-то делать с этим обновленным значением, например, посчитать что-то на его основе и получив из-за этого неправильные результаты.

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

Спасибо) да я туплю иногда, когда думаешь на одном, говоришь на втором и наоборот 🤡

@@dev_pushkin Не знаю, мне манера речи и понравилась). Особенно с поправкой на то, что нужно достаточно сложные концепции объяснить.

Спасибо) ну да, это довольно не просто делать)

Ты немного запутался. Не верь вики и проверь сам в следующем видео. И посмотри ещё видео про concurrency control. Про снэпшот тоже - постарайся не использовать вики как first source of truth. И старайся, когда слово слышишь, учитывать контекст и его смысл, назначение. Он может меняться в разных контекстах. Это важно. В видево я ещё говорил про SI и SSI. Посмотри, какие это уровни.

Видел такое, да. Не стал включать, так как чаще используется для блокировки на ресурс, но покрывается другими способами, про которые говорили. Усложняет логику программы самой, не всегда будет ясно, когда анлок делать и не сделать это с конфликтом или вообще забыть сделать. Добавляет дополнительно лишний запрос. Думаю, оно может в некоторых специфичных местах заюзаться. Типа залочить заказ на всегда, пока не разлочу сам вручную. Но, могу забыть и тд. Начинаются ручные анлоки, и проч. Вы ещё работаете с ним или забыли просто анлок? Вариант, если ресурсов мало и таких моментов мало. Получается оч жёсткий хороший контроль. Если их миллионы, то там уже не получится

Ну и сам понимаешь, помимо нагрузки и лишнего запроса оно тормознет жёстко. Тут я бы больше с пессимистик сравнивал, а не с версиями. Они больше при параллельной работе и обновлениях. Миллионы запросов и они spare по отношению к разделяемым ресурсам.

Ну я там говорил про версии, что мы их сами меняем в запросе. Тебе надо инкрементировать вручную для атомарности. А использовать можно и timestamp или что-то ещё, но чаще version. Compare and swap idiom.

Пожалуйста :)

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

@@dev_pushkin понял, спасибо. Сам Джун, но я каким то образом запоминаю все сразу что ты говоришь ( ну или 99%)

Привет! Спасибо за коммент. На самом деле там нет противоречий. Могу использовать cqrs в любом виде, с event sourcing и без. Я бы мыслил немного с противоположной точки зрения, которая будет более generic и покроет частный случай с event sourcing. Я там уточнял в видево про сам паттерн, принцип и как он используется. Его реализация может быть разными способами. Говорим не про конкретную реализацию и event sourcing, к примеру , а принцип.

@@dev_pushkin так про то и речь, что CQRS в данном контексте проблему race condition сам по себе не решит, а вот event sourcing - решит

Да, я понимаю, о чем он говорил. Проблем с этим нет, я просто мыслил в других категориях немного. Спасибо за коммент!

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

Вообще, ты очень чётко это подметил. Спасибо :)

Это чтобы точно все поняли

@@Niki-nx6cd Угу. Повторение повторение - мать учения мать учения. А если серьёзно - то действительно выбросив повторы видео можно сделать вполовину короче.

В SQL операторы всегда выполняются в рамках какой-либо транзакции: либо явно созданной, либо неявно созданной. То что автор называет атомарной операцией на самом деле оператор, выполняющийся в неявно созданной транзакции. Также и в вашем случае, перед выполнением запроса будет неявно создана транзакция.

Привет! Добавил в описание!

​@@dev_pushkin❤

Привет! Можешь еще посмотреть обсуждения в комментах про это. Там немного разобрали. В пределах одной транзакции от сервиса - это скорее ошибка мышления "транзакция все сама сделает" + логическая ошибка в коде. Обнаружить возможно даже не сразу получится. Более реальная ситуация - например посылать со странички redmine параллельно запросы на update. Транзакцию долго держать не получится и толку от Serializable никакого не будет. Я об этом хочу в следующем видео побрейнштормить.

@@dev_pushkin итак понимаю Select for update наше все :)