1. 1C / Говнокод #20464

    −93

    1. 1
    2. 2
    3. 3
    4. 4
    Функция ПеревестиДеньги(СчетИсточник, СчетПолучатель, Сумма)
            СнятьСоСчета(СчетИсточник, Сумма);
            ПополнитьСчет(СчетПолучатель, Сумма);
    КонецФункции

    Как написать эту функцию безопасно? Что делать, если ПополнитьСчет упадет с исключением, например?

    Запостил: LispGovno, 03 Августа 2016

    Комментарии (28) RSS

    • #Исключения #Атомарность #Конкурентность
      Ответить
    • В транзакции же
      Ответить
    • О, моя любимая хуйня.
      Иногда хранилище поддерживает транзакции только на одном ключе за раз.
      Тогда приходится писать журналируемую систему, в которую ты пихаешь запись "создать BalanceChanged [id=<uuid 1>, value=10], создать BalanceChanged [id=<uuid 2>, value=-10]", после этого рапортуешь пользователю об успехе и пытаешься применить это говно. А в фоне у тебя еще ходит разведчик журнала, который регулярно проверяет, не упал ли кто посередине операции, подбирает эти операции, создает записи, если их нет, ебаный ад, в общем.
      Ответить
      • > Иногда хранилище поддерживает транзакции только на одном ключе за раз.

        это как это? транзакция покрывает серию действий, при чем тут ключи?
        Ответить
        • > транзакция покрывает серию действий

          По техническим причинам в данной реализации максимальное количество действий в одной транзакции — 1
          Ответить
          • ... и чем это отличается от отсутствия транзакций?
            Ответить
            • Тем, что в рекламе можно написать про транзакции и их пользу.
              Ответить
              • мля, типа даже sqlite умеет больше:
                https://www.sqlite.org/transactional.html
                https://www.sqlite.org/atomiccommit.html
                Ответить
        • Привет из двадцать первого века! Тут, кроме SQL, есть другие хранилища, в частности распределенные.

          > это как это? транзакция покрывает серию действий, при чем тут ключи?

          Это так, что без транзакции один и тот же ключ могут обновить сразу несколько потребителей, что приведет к недетерменированному результату: сразу два узла кластера начнут реплицировать разные значения по всему кластеру, и какое из них выиграет, зависит от стратегии разрешения конфликтов. В случае с транзакциями такая ситуация невозможна.
          Ответить
          • > Привет из двадцать первого века! Тут, кроме SQL, есть другие хранилища, в частности распределенные.

            Привет из двадцатого века! SQL это всего лишь язык, и распределенные хранилища появились намного раньше чем "не вчера" и "двадцать первый век". не говоря уже про распределенные транзакции.

            > Это так, что без транзакции один и тот же ключ могут обновить сразу несколько потребителей

            ну так бы и сказал что NoSQL. это ихняя собственная специфика реализации транзакций. которая опять таки не нова.
            Ответить
            • > NoSQL
              FoxPro - тоже NoSQL. И в нём тоже прикручивали транзакции через анус :)
              Ответить
              • Носыкуль не взлетел. Слава реляционкам!
                Ответить
          • и как, давно кассандру к 1с можно прицепить?
            Ответить
            • а я и не про 1с, я про проблему
              Ответить
              • проблема не поменялась. инкрементальные апдейты и eventual consistency с бизнес приложениями не сильно дружат. какому пользователю понравится ответ от банка что у него на счету лежит "приблизительно" столько денег. или ответ от фирмы то что оплата "может быть уже прошла".

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

                латание данных в ручную не такая больша проблема в реальной жизни, на самом деле. проблема что производители NoSQL решений в лоб не предоставляют ни каких гарантий на консистентность данных. у них просто нет того глубокого фундамента по сравнению с IMB DB2 и Oracle.
                Ответить
                • К железу-то какие требования? Там требования к протоколам консенсуса, которые в свою очередь выливаются в требования к прогерам, которые матерятся и читают спеку по паксосу.

                  > проблема что производители NoSQL решений в лоб не предоставляют ни каких гарантий на консистентность данных.

                  У нас кроме AP систем еще и CP системы, если что.
                  Ответить
                  • > К железу-то какие требования? Там требования к протоколам консенсуса, которые в свою очередь [...]

                    ... в отсутствии гарантировано надежной сети, консенсус могут настолько долго пытаться достигать, что какая другая нода опять слетить, и придётся процесс по новой начинать.

                    для eventual consistency и типичного уровня ренундантности в NoSQL (x3, x5, и больше) это не большая проблема. но для полноценных распределенных транзакций это весьма болезненно - учитывая что они сидят часто в тех приложениях которые ко всему прочему еще и soft real-time хотят.

                    хотя слышал что некоторые NoSQL халявят, и тоже split brain страдают.

                    > У нас кроме AP систем еще и CP системы, если что.

                    Не в курсе.
                    Ответить
                    • Все нормальные системы принимают (Network) Partition Tolerance (тот самый P в AP/CP) как неизбежность, поэтому требований к сети на самом деле нет. Паксос - это одно из решений проблемы нестабильной работы узлов / коммуникации, пришедшее к нам еще со времен ебанутых греков-депутатов, и оно с некоторыми оговорками real-time (безусловно, есть варианты при которых клиент останется в неведении относительно конечного результата, но консенсус по вопросу рано или поздно будет достигнут). Ничего заново начинать не надо, в случае падения координатора его работу подберет другая нода в том состоянии, в котором она есть.

                      > для eventual consistency и типичного уровня ренундантности в NoSQL (x3, x5, и больше) это не большая проблема.

                      Смотря что под этим имеется в виду. AP (Available / Partition tolerant) системы и вправду могут принимать на одном узле и асинхронно реплицировать, но конфликты одновременного обновления остаются.

                      Но про "клиент не знает, применилась ли операция" есть самая мякотка.

                      Дело в том, что даже в случае с SQL сервер + клиент являются распределенной системой с 2PC. И если клиент на запрос коммита транзакции получает сообщение "разрыв сети", он не знает, применилась ли транзакция.

                      Такие дела.
                      Ответить
                      • > Дело в том, что даже в случае с SQL сервер + клиент являются распределенной системой с 2PC. И если клиент на запрос коммита транзакции получает сообщение "разрыв сети", он не знает, применилась ли транзакция.

                        ... почему для HA (high availability), первым делом клиент/сервера учатся поддерживать сессии которые не привязаны к конкретному соединению, и после fail over умеют распозновать статус последнего обломавшегося запроса.

                        в дешевых решениях народ это часто делает в ручную (после переподключения, проверить прошла последняя транзакция или нет).

                        но например Oracle RAC (не в курсе про остальные HA RDBMS) умеет и без модификации приложения, прозрачно для приложения.(*)

                        > Такие дела.

                        You don't say?

                        (*) ок, они хотят модификацию приложения, но это только один глобальный on error который говорит что если соединение обламалось, то надо магический реконнект делать без сброса сессии.
                        Ответить
                        • > без модификации приложения
                          Локальный write-ahead log ведут?
                          Ответить
                          • нет. полная репликация сессий на сервер-сайд между мастером и хот стэндбаем.
                            Ответить
                            • Ох, т.е. на каждом клиенте болтается полная копия данных? Энтерпрайзненько...

                              З.Ы. Или только тех, которые сам клиент отправлял в сессиях?
                              Ответить
                              • > Ох, т.е. на каждом клиенте болтается полная копия данных? Энтерпрайзненько...

                                в смысле? на клиенте так или иначе должна болтаться копия данных последнего запроса - все остальное делает сервак.

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

                                > Или только тех, которые сам клиент отправлял в сессиях?

                                Хез. Но с точки зрения расхода памяти, побочных эффектов на клиенте не наблюдалось.

                                Единственное что оракл открыто описывал это то что финальная точка синхронизации это коммит, и желательно мелких транзакций избегать. (Но размер транзакций уже давно конфигурируемый параметр почти у всего софта который там крутится, поэтому это не проблема.)
                                Ответить
                      • Не может не быть требований к сети. FLP это как бы доказали еще 100500 лет назад. Возможны только варианты, где есть "ораклы" с точными синхронизируемыми часами и т.п. "уловками". Чтобы их обеспечить, сеть должна быть в каком-то смысле "надежной", т.е. как правило, надежность выражается в минимальной скорости, минимальном количестве потеряных пакетов и т.п.
                        Но, на самом деле, это нужно, не только для алгоритмов, а чтобы знать, с кого страховку сбивать, я так понимаю.
                        Ответить
    • показать все, что скрытоОдинЭсРулит! Не то что эти ваши Питоны, Джавы и прочее говнище неповоротливое! 1С в каждый дом, в каждую компанию! УРА-а-а-а, товарищи! ДаПрибудетСВамиСвет!
      Ответить
    • Зачем это называется "функция"?
      Ответить

    Добавить комментарий