Мне кажется автор просто не удачно назвал статью, тем самым притянув не ту аудиторию. Статья вообще не про "денежные переводы". И тут я понимаю Вы все прекрасно расписали.
В моем понимании, статья только как выполнить конкурентный update без lost update и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
От ваших пояснений толку нет, у вас в коде явно commit на 2 шаге, который закроет транзакцию и 3 шаг будет в новой транзакции. Код лучшее пояснение, а он с ошибками.
Ну так тут еще фееричнее, 3 и 4 вариант, делают все проверки, а потом закрывают транзакцию, и потом просто фигачат update, а то что между закрытием транзакции и update может быть все что угодно, автор не думает.
Коллеги, вы слишком глубоко копаете, на мой взгляд, статья простая и тема ее не финансовые системы - тут полный швах. А просто рассказ об уровнях изоляции и проблемах с ними связанных.
Ой, с отчетами конечно оффтопик: но там основная причина это исправление данных задним числом и отсутствие версионности данных в системе. Если система не позволяет получить отчет за январь, в том виде как он выглядел в момент принятия решения, скажем 10 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.
Еще одно замечание: в реальном коде нужно разделять почему не получился перевод: из-за отсутствия средств на счете или из-за ошибки параллельного доступа к счету. Во втором случае код должен содержать повтор операции, о чем в статье не написано. Это применимо ко всем вариантам, кроме варианта с пессимистичной блокировкой.
Это понятно, я писал реальную банковскую систему и видел внутри еще 2-3. И там все сложнее. Понятно что там есть стадийность принятия решения, есть системы где есть остаток на начало дня и все остальное досчитывается, есть системы где есть несколько остатков (прогнозный и реальный). Если добавить карты то там еще "чудесатее" - и остаток на карте и счете - несколько дней после совершения операции разный.
Но это все не важно. Я воспринимаю статью как шаблон для того что бы показать подходы борьбы с проблемами параллельного доступа к данным в транзакционных системах. И тут важно исправить ошибки, о которых я писал выше.
Последние 2 варианта содержат ошибку в реализации - фиксация транзакции на шаге 2, до update - обнуляет все усилия. Между шагом 2 и 3 могут втиснуться любые транзакции, а блокировки уже сняты.
Вот этот текст, на мой взгляд спорный:
"Особенности: зависит от реализации: при Snapshot Isolation — аналог оптимистической блокировки с версией, при блокировках — аналог пессимистической блокировки"
В стандарте SQL, для этого уровня блокировки, при совершении обновления строк измененных с момента начала транзакции должно выдать ошибку (которую приложение должно быть готово обработать), в той же версионной СУБД PostgreSQL возникает по факту ожидание снятие блокировки изменённой другой транзакцией строки (вдруг там rollback и все же можно), что приводит нас что даже в версионниках будет ожидание как в пессимистическом варианте. Тут конечно автор может предположить о существовании другой версионной СУБД где такого ожидания не происходит, но я о такой не знаю (в другом популярном версионнике Oracle - нет Repeatable Read). В целом такие истории, наверное, лучше рассматривать в привязке к СУБД.
Да что вы заладили про "в России редкость". Я уже писал толковый разработчик, не тимлид в России зарабатывет 250-300к. Тимлид, сеньйор, архитектор умножайте на 2.
Причем, после ковида, уже регион не важен, я как то собеседовал парня из Якутии и зп ожидания были такие же. В итоге он выбрал другую компанию.
Да наверное, сельский житель зарабатывает меньше в разы, но так и в любой другой стране.
Ну тут же все от тебя самого зависит, учился, выбрал востребванную професию, так и зарабатывать будешь. А не учился, так ворочай...
Сейчас опять минусов напихают, но я правда так считаю. Да есть врачи, педагогии которым платят мало, и это не правильно. Хотя у меня приятель толковый хирург получает больше меня.
В России ни в чем не возможно быть уверенным, но сын окончил МГУ, успешно работает, я помог ему закрыть ипотеку. Дальше сам пускай, куда уж больше...
Я баланс нашел, работаю 8 часов, денег хватает, есть время на хобби/друзья/каждодневный гейминг. Никакой иллюзии... Вопрос ценностей и приоритетов.
Вот, честно давайте закончим, Вы пытаетесь меня на свои ценности натянуть, а я Вас. Изначально целеполагание разное, мне Ваши ценности не интересны, наверное и Вам мои.
А для меня глупо пытаться заработать все деньги мира, не получая от мира удовольствия: концерты, театр, общение с друзьями и др. Это не значит что я не люблю свою работу, но это просто треть моей жизни не больше и не меньше. Для меня баланс важнее. Вот честно сильно в сторону ушли, давайте закончим. Сильно оффтопик.
Нет, HoT update тоже влияет, как на место так и время работы.Но просто меньше, чем update индексированных полей.
Это же postgres судя по тегам, кто мешает просто написать ROLLUP или CUBE или GROUPING SETS в GROUP BY?
Зачем изобретать то что есть уже в SQL?
Мне кажется автор просто не удачно назвал статью, тем самым притянув не ту аудиторию. Статья вообще не про "денежные переводы". И тут я понимаю Вы все прекрасно расписали.
В моем понимании, статья только как выполнить конкурентный update без lost update и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
Вопрос наверное не ко мне, а к автору статьи.
Собственно он статьей на Ваш вопрос и отвечает, что делать и какие патерны серилизации применять.
Да, так будет работать.
Комментарий по фантомным чтениям относился к варианту досчета остатка по транзакциям.
Исправьте код, выше писал, у Вас там явно commit который явно закроет транзакцию, толку от таких пояснений нет, если код кривой.
Если не понимаете как, то просто уберите из 3 и 4 варианта на 2 шаге:
}else{ commit();От ваших пояснений толку нет, у вас в коде явно commit на 2 шаге, который закроет транзакцию и 3 шаг будет в новой транзакции. Код лучшее пояснение, а он с ошибками.
Новичок скопирует код и получит ерунду.
Ну так тут еще фееричнее, 3 и 4 вариант, делают все проверки, а потом закрывают транзакцию, и потом просто фигачат update, а то что между закрытием транзакции и update может быть все что угодно, автор не думает.
А вот тут еще и фантомные чтения надо рассматривать в тему статьи.
Да к ИТшникам просто так не приходи, народ дотошный )))
Нужно очень аккуратно формулировать тему и пример, а то получишь 100500 замечаний на другом уровне абстракции )))
Коллеги, вы слишком глубоко копаете, на мой взгляд, статья простая и тема ее не финансовые системы - тут полный швах. А просто рассказ об уровнях изоляции и проблемах с ними связанных.
Ой, с отчетами конечно оффтопик: но там основная причина это исправление данных задним числом и отсутствие версионности данных в системе. Если система не позволяет получить отчет за январь, в том виде как он выглядел в момент принятия решения, скажем 10 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.
Еще одно замечание: в реальном коде нужно разделять почему не получился перевод: из-за отсутствия средств на счете или из-за ошибки параллельного доступа к счету. Во втором случае код должен содержать повтор операции, о чем в статье не написано. Это применимо ко всем вариантам, кроме варианта с пессимистичной блокировкой.
Это понятно, я писал реальную банковскую систему и видел внутри еще 2-3. И там все сложнее. Понятно что там есть стадийность принятия решения, есть системы где есть остаток на начало дня и все остальное досчитывается, есть системы где есть несколько остатков (прогнозный и реальный). Если добавить карты то там еще "чудесатее" - и остаток на карте и счете - несколько дней после совершения операции разный.
Но это все не важно. Я воспринимаю статью как шаблон для того что бы показать подходы борьбы с проблемами параллельного доступа к данным в транзакционных системах. И тут важно исправить ошибки, о которых я писал выше.
Последние 2 варианта содержат ошибку в реализации - фиксация транзакции на шаге 2, до update - обнуляет все усилия. Между шагом 2 и 3 могут втиснуться любые транзакции, а блокировки уже сняты.
Вот этот текст, на мой взгляд спорный:
"Особенности: зависит от реализации: при Snapshot Isolation — аналог оптимистической блокировки с версией, при блокировках — аналог пессимистической блокировки"
В стандарте SQL, для этого уровня блокировки, при совершении обновления строк измененных с момента начала транзакции должно выдать ошибку (которую приложение должно быть готово обработать), в той же версионной СУБД PostgreSQL возникает по факту ожидание снятие блокировки изменённой другой транзакцией строки (вдруг там rollback и все же можно), что приводит нас что даже в версионниках будет ожидание как в пессимистическом варианте. Тут конечно автор может предположить о существовании другой версионной СУБД где такого ожидания не происходит, но я о такой не знаю (в другом популярном версионнике Oracle - нет Repeatable Read). В целом такие истории, наверное, лучше рассматривать в привязке к СУБД.
Да что вы заладили про "в России редкость". Я уже писал толковый разработчик, не тимлид в России зарабатывет 250-300к. Тимлид, сеньйор, архитектор умножайте на 2.
Причем, после ковида, уже регион не важен, я как то собеседовал парня из Якутии и зп ожидания были такие же. В итоге он выбрал другую компанию.
Да наверное, сельский житель зарабатывает меньше в разы, но так и в любой другой стране.
Ну тут же все от тебя самого зависит, учился, выбрал востребванную професию, так и зарабатывать будешь. А не учился, так ворочай...
Сейчас опять минусов напихают, но я правда так считаю. Да есть врачи, педагогии которым платят мало, и это не правильно. Хотя у меня приятель толковый хирург получает больше меня.
В России ни в чем не возможно быть уверенным, но сын окончил МГУ, успешно работает, я помог ему закрыть ипотеку. Дальше сам пускай, куда уж больше...
Я баланс нашел, работаю 8 часов, денег хватает, есть время на хобби/друзья/каждодневный гейминг. Никакой иллюзии... Вопрос ценностей и приоритетов.
Вот, честно давайте закончим, Вы пытаетесь меня на свои ценности натянуть, а я Вас. Изначально целеполагание разное, мне Ваши ценности не интересны, наверное и Вам мои.
Ну я немного занимался АСУ ТП в 90е, там все же есть задачи на оптимизацию, как затолкать программу в мизерный объем...
Возможно уже не актуально ...
А для меня глупо пытаться заработать все деньги мира, не получая от мира удовольствия: концерты, театр, общение с друзьями и др.
Это не значит что я не люблю свою работу, но это просто треть моей жизни не больше и не меньше. Для меня баланс важнее.
Вот честно сильно в сторону ушли, давайте закончим. Сильно оффтопик.
P.S. я базу закрыл