svcoders_ustinovВ результате получил те же проблемы, которые видел и у других - блокировки и как результат медленный расчет резервов (иногда) и потери резервов. Например при перемещении с центрального склада на склад филиала одновременно должен "переместиться" и резерв, и вот тут то и возникали проблемы (тормоза и потери резервов).

Зачем вы ставите в один ряд абсолютно независимые события, тормоза не могут являться причиной потери резервов, к этому может привести только ошибка в логике
s_ustinovИ в один не очень прекрасный момент склад не смог отгрузить все перемещения, так как медленно учитывались отгрузки - кладовщики блокировали друг друга (пересчет резервов при учете перемещений).

Взаимоблокировки это всегда ошибка в логике

В целом согласен - это ошибки логики.
svcoders_ustinovИ пришлось придумывать другую реализацию - без блокировок . Заодно и проблему с "потерянными" резервами решили (она в старой реализации тоже была).

Как и в исходной ветке весь спор скатывается к сравнению блокировочников и версионников. Ответить на вопрос справится ли 1с с той нагрузкой, с которой у вас справляется навик сможет только реализация и испытание подобной системы резеруирования на платформе 1с. Но я не думаю, что будут какие то проблемы.
авторПопробуйте прописать алгоритм действий при событии "уменьшение количества в одном из заказов клиента", а потом при событии "уменьшение остатка на складе" (например при недостаче)..
Не вижу особой сложности, просто не нужно пытаться каскадно поменять все резервы, достаточно обработать существующие резервы, начиная с последнего. Если вы пообещали клиенту, что его заказ прибудет 10 числа, ничего плохого не произойдет, если резерв отмененного заказа на 5 число, достанется заказу, который был запланирован на 15 число

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

Ок. Давайте обсудим конкретный пример.
Три события происходят "почти одновременно", то есть с разницей в несколько миллисекунд.
Событие 1. На "Склад А" учитывается поступление от поставщика, которое включает поступление 100 штук товара "Т".
Событие 2. Со "Склад В" списывается 5 штук товара "Т" (обнаружили недостачу).
Событие 3. В филиале "Склад С" учитывается заказ продажи (формируются резервы) на 15 штук товара "Т". Филиалу "Склад С" разрешено резервировать товары на "Склад С", "Склад В", "Склад А".
При этом существует несколько других заказов продажи с товаром "Т", под которые сформированы резервы. В том числе резервы были и в заказе покупки, по которому идет поступление на склад (событие 1), и на "Склад В", на котором обнаружили недостачу (событие 2), и на "Склад С", где учитываем новый заказ.

Каким, по вашему мнению, должен быть корректный (без ошибок логики) алгоритм резервирования и как он должен отработать в данном случае?
svcoder Взаимоблокировки это всегда ошибка в логике

_bobs_ustinovпропущено...

В решении проблемы с блокировками (тормоза и потери резервов).

Сделать быстрый асинхронный пересчет резервов в навике проще - можно ЛЕГКО писать с помощью SQL прямо в таблицы навика. А вот как сделать что то с аналогичным результатом в 1С (не с помощью SQL - писать сиквелом в таблички БД, в которых "хранятся" регистры 1С мне как-то совсем не хотелось) я в свое время придумать так и не успел (перешел на другую работу).

1. чем таблицы навика эскуэльнее таблиц 1С ? То, что вы не разобрались в архитектуре хранения данных и не умеете отследить профайлером что куда пишется, это понятно...вопрос именно об эскуэльности таблиц )))

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

_bob2. что помешало хранить пересчитанные резервы в отдельной таблице? все равно функционал нетиповой, какая разница, с регистрами играться или завести просто SQL таблицу и спокойненько в нее пересчитывать....или регистр сведений, в который писать кодом SQL куда как проще, чем в остатки
Примерно так и собирались поступить, если не смогли бы найти возможность сделать штатными средствами 1С (реализовать полностью отдельный модуль с расчетами на SQL). Только это не настолько легко, как вы описываете.

svcoders_ustinovОк. Давайте обсудим конкретный пример.
Три события происходят "почти одновременно", то есть с разницей в несколько миллисекунд.
Событие 1. На "Склад А" учитывается поступление от поставщика, которое включает поступление 100 штук товара "Т".
Событие 2. Со "Склад В" списывается 5 штук товара "Т" (обнаружили недостачу).
Событие 3. В филиале "Склад С" учитывается заказ продажи (формируются резервы) на 15 штук товара "Т". Филиалу "Склад С" разрешено резервировать товары на "Склад С", "Склад В", "Склад А".

Зачем вы вносите неопределенность в условия задачи? Если в начале алгоритма резервирования установить необходимые блокировки , все эти события очень даже упорядочены и их логика очевидна. При поступлении резервы в заказе заменяются на резервы склада, списание со склада меняет последние резервы со склада на следующие по доступности. Ну про заказ и так все понятно
А где оно, начало алгоритма резервирования, для события 1? И какие блокировки необходимо установить?
При старте проведения поступления на склад? Или после проведения (записи в регистры) модуль резервирования вызывается отдельно? Если при старте проведения - то учет поступления может выполняться довольно долго (несколько сотен позиций + пересчеты резервов) - и всё это время остальные документы заблокированы... А если после проведения - то получится, что остатки уже обновлены, а резервы еще нет, и может вклиниться заказ покупателя (событие 3) и забрать резервы себе...

Например, при старте учета поступления на склад блокируем регистр резервов для всех товаров, которые в этом поступлении. Но тогда мы не сможем учесть ни одного документа с этими товарами (перемещение между складами, списание, отрузка покупателю и т.п.) - ведь все эти документы должны менять резервы... А установив менее строгие блокировки можем получить в результате взаимные блокировки и потери резервов.

Когда рассуждаешь "в принципе" - всё легко. А при попытке это реализовать проявляются нюансы...

svcoders_ustinovВо вторых, есть такая вещь, как изменение версии платформы 1С. Иногда версию менять надо (по разным причинам), а что может произойти при смене версии платформы вы, вероятно, и сами знаете.
Последние изменения в языке запросов происходили при переходе с 8.1 на 8.2 т.е. 8 лет назад. Из-за необходимости поддержки oracle, пришлось отказаться от некоторых конструкций, а для некоторых добавили ограничения

При чем тут язык запросов?

Сама 1С ясно написала:

http://v8.1c.ru/metod/faq2/answer.jsp?id=493]Как просмотреть структуру таблиц информационной базы?
...

Для этого используется функция ПолучитьСтруктуруХраненияБазыДанных(). Она возвращает информацию о структуре таблиц базы данных всех объектов конфигурации (в виде таблицы значений).

...

ВНИМАНИЕ

Полученная информация предназначается для административных задач обслуживания базы данных и анализа записей технологического журнала.

Не рекомендуется использовать её для реализации какой-либо части прикладной функциональности .


Я даже догадываюсь, почему не рекомендуется:

http://downloads.v8.1c.ru/content//Platform/8_3_7_1845/1cv8upd.htm]Переход с предыдущей версии на версию 8.3.6

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

svcoder,
вас действительно не напрягает вариант с записью в таблицы 1С (которые создала платформа) с помощью SQL?
Лично мне такой вариант совсем не нравится...

_bob, svcoder
Не надо меня убеждать, что в 1С с помощью кода на SQL можно создать модуль резервирования - я знаю, что можно.
Вопрос в другом - как можно реализовать резервирование штатными средствами 1С (в конфигураторе)? Естественно, реализовать без ошибок в логике и тормозов.

_bobs_ustinov, а вы знаете, обычно после написания и внедрения нетипового функционала ни конфигурацию ни технологическую платформу НЕ ОБНОВЛЯЮТ
Знаю.
Довольно много фирм до сих пор на 1С 7.7
Вы считаете, что это хорошо? Технический долг
Да и в некоторых случаях платформу приходится обновлять...

_bobа зачем?
вы на навике штатными средствами без ошибок в логике и тормозов сделать этого не смогли
воплотить практически любой замудреный алгоритм резервирования товара штатными средствами 1С (в конфигураторе) МОЖНО, но есть шанс налететь на тормоза
все же надо отдавать себе отчет, что существуют ограничения, и некоторые процессы даже для очень небольшой компании невозможно воплотить на 1С
Когда разбирались с этой задачей в навике - почти сразу стало понятно, что средствами нава (на C/AL) эту задачу не решить - не хватит скорости.
А когда начали разбирать такую же задачу в 1С (в другой фирме) - то всё было не столь очевидно. Платформа 1С намного больше фич содержит. Язык запросов, менеджер временных таблиц - вроде бы почти всё получалось...
Да и навик подружить с сиквелом существенно проще и удобнее, чем 1С с сиквелом... Вот и думали, как это в 1С сделать...

Потом я переехал, и, насколько знаю, резервирование до ума там так и не довели - кроме меня некому было на сиквеле писать, все остальные только с 1С работали. А меня до сих пор мучает вопрос - может, все же можно это в самой 1С сделать? Мы могли упустить какую-то возможность...

svcoders_ustinovА где оно, начало алгоритма резервирования, для события 1? И какие блокировки необходимо установить?
При старте проведения поступления на склад? Или после проведения (записи в регистры) модуль резервирования вызывается отдельно? Если при старте проведения - то учет поступления может выполняться довольно долго (несколько сотен позиций + пересчеты резервов) - и всё это время остальные документы заблокированы... А если после проведения - то получится, что остатки уже обновлены, а резервы еще нет, и может вклиниться заказ покупателя (событие 3) и забрать резервы себе...
При поступлении никаких алгоритмрв резервирования вызывать не нужно. Нужно перенести резервы из размещения заказа на склад . При списании нужно блокировать, но в чем проблема? Это не такая частая операция по сравнению с обычным порядком резерв-поступление-отгрузка.

Вы пробовали использовать управляемые блокировки 1с? Они работают быстрее блокировок БД и гораздо позже эскалируются.
Перенос резервов - это тоже алгоритм резервирования. Просто перенести резервы не получится - поступление далеко не всегда равно заказу. Мы не в идеальном мире живем, и всегда можно наткнуться на разницы (пересортица, например). Поэтому резервы надо пересчитать.
Вопрос - в какой момент использовать блокировки, чтобы не нарушить логику работы? Если вызвать слишком рано - автоматом появятся тормоза, так как резервы будут узким местом. Если чуть позже - риск взаимных блокировок и потери резервов.
И управляемые блокировки в данном случае ничем не помогают.
При детальном анализе у меня получилось, что единственный вариант с правильной логикой работы и без тормозов - асинхронный вызов пересчета резервов. Но как сделать это в 1С - не понятно.

_bob, ну я никогда не утверждал, что крут именно как программист 1С
В 1С у меня средний уровень.

_bob4. РЗ "пересчитыватель" которое по таймеру берет из регистров задания , пересчитывает резервы и записывает в регистр "выполненные_пересчитывателем_задания" ИД выполненных заданий, чтоб их второй раз не выполнять


А можно уточнить, как именно вы это сделали?

Я думал использовать:


Но мне сказали, что это не будет работать так, как нужно.
Нужно, чтобы каждую секунду запускался новый экземпляр процедуры пересчета резервов независимо ни от чего. Например в 11:40:10 запустился один экземпляр процедуры "ПересчитатьРезервы", в 11:40:11, не дожидаясь завершения предыдущего запуска, запустился еще один экземпляр процедуры "ПересчитатьРезервы", в 11:40:12 запустился третий экземпляр (при этом всё еще работает запущенный в 11:40:10, а например запущенный в 11:40:11 уже завершил работу) и т.д.
Мне сказали, что так в 1С не будет параллельно выполняться несколько экземпляров процедуры "ПересчитатьРезервы".

Или мне сказали неточные сведения, и ПодключитьОбработчикОжидания будет работать так, как надо для этой задачи?

_bobя считаю что это замечательно, когда люди не тратят деньги на ненужные обновления софта
как замечательный пример: система бронирования билетов в РЖД, система бронирования авиабилетов в США, обе написаны на коболе под AS/400 столетие назад, ну и знаменитая АБС Equation (PRG/400 под AS/400), в Альфа-банке радостно юзают и не жужжат

Одно дело, когда обновление не нужно.
А другое дело, когда обновление очень нужно (новые фичи всем бы пригодились), но из-за "технического долга" перейти на новую версию очень дорого.

OremaxУважаемые коллеги.
Поскольку я не являюсь специалистом 1С и MS Dynamics мне не совсем понятно почему в этой теме говорят о проблемах с блокировками и как следствие с "тормозами"?
Как работает механизм блокировок?
Есть ли возможность при обработке данных управлять транзакциями и уровнями изоляции транзакций?
Именно для резервирования на нескольких складах тема блокировок является ключевой.
Если реализовывать алгоритм без логических ошибок "в лоб" - надо очень рано вызывать блокировки, и тогда пользователи будут постоянно блокировать друг друга - всё будет тормозить. А если попытаться блокировать данные попозже, чтобы уменьшить блокировки - начинаются логические ошибки (потери резервов).
И в 1С, и в навике управлять блокировками можно... Но...
В 1С сделали свой механизм управляемых блокировок, который работает "выше" транзакций СУБД, и программисту надо самому продумывать, что и в какой момент блокировать для обеспечения целостности данных. Автоматические блокировки в 1С тоже есть, но с ними масштабируемость совсем плохая.
В навике блокировки автоматические на уровне MS SQL, сам нав только стартует транзакции. Из кода нава можно вызвать коммит, если принудительно надо разбить код на несколько транзакций. Но в наве проблема с масштабируемостью не связана напрямую с транзакциями. У многих таблиц есть поле "Entry No" - номер операции, которые идут последовательно по возрастанию - 1,2,3,4 и т.д. И этот номер генерируется кодом нав, а не автоинкремнтом СУБД... Так что всё печально...

А уровнем изоляции транзакций, насколько знаю, ни там ни там управлять нельзя.