Коллеги, что вы думаете о данном коде? 2MikeR

[belugin]

Цитата:

Сообщение от MikeR

Скажем так, я переделал - работать стало ЗНАЧИТЕЛЬНО быстрее, сбоев не было вообще, проценты - это оценочное суждение

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

[MikeR]

Цитата:

Сообщение от belugin

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

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию, вешать блокировку while select forupdate по обновляемым таблицам? Иначе тоже может произойти пук и мы потеряем целостность, то есть запишем в таблицу налогов одни цифири, а допустим документы не обновим.

[macklakov]

Цитата:

Сообщение от MikeR

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию

Насколько я понимаю, именно в этом смысл транзакции и есть.

[S.Kuskov]

Цитата:

Сообщение от MikeR

допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию, вешать блокировку while select forupdate по обновляемым таблицам?

Если объемы необходимых изменений столь велики, то методологически правильно сначала вне транзакции выполнить все долгие вычисления и получить "грязные" данные, а потом в одной транзакции минимально затратным способом их применить "на чисто", естественно убедившись что с момента вычисления данные не устарели. Конечно поддержка такого рода механизмов изначально должна быть заложена в архитектуру данных. Например, хорошо когда архитектура данных позволяет вместо полного пересчета устаревших данных, учесть в новом расчете только новые изменения, произошедшие с момента предыдущего расчета.

И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь.

[MikeR]

Цитата:

Сообщение от S.Kuskov

И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь.

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

[belugin]

Цитата:

Сообщение от MikeR

Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию,

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

См. также давнишнюю статью Fed'а про то, как избегают блокировок в inventory