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

для спящего время бодрствования равносильно сну

Программист 1сАлексей2003вся проблема в том, что в управляемых блокировках, при запросах к скулю выставляются блокировки по-умолчанию скулем. а это эскалация блокировок. поэтому 1с в 700 пользователей при одновременной работе (все изменяют данные, даже только свой "склад") то работать не будет. не тешьте себя. проверено.

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

+ а учитывая что все новые записи у 1с имеют близкое друг к другу значение (ГУИД всегда на сервере формируется) то новые записи будут находиться близко друг к другу, а значит большой шанс, что соседние записи заблокируются.
1сникам надо менять схему блокировок в запросах. ставить rowlock, тогда у меня проводятся ВСЕ документы кроме текущего. (вешал блокировку на таблицу движений регистра накопления остатков без таблицы итогов). или переходить уже на снапшот изоляцию например.

для спящего время бодрствования равносильно сну

RederА вот интересно у некоторых людей, коих я знаю лично, на 7-ке 500 пользователей в одной базе тянуло.
v7++ - прямые запросы к скулю, поэтому лехко. 1ска занимается только отображением данных.

Программист 1сАлексей2003+ а учитывая что все новые записи у 1с имеют близкое друг к другу значение (ГУИД всегда на сервере формируется) то новые записи будут находиться близко друг к другу, а значит большой шанс, что соседние записи заблокируются.
1сникам надо менять схему блокировок в запросах. ставить rowlock, тогда у меня проводятся ВСЕ документы кроме текущего. (вешал блокировку на таблицу движений регистра накопления остатков без таблицы итогов). или переходить уже на снапшот изоляцию например.

для спящего время бодрствования равносильно снуХм а насколько большой шанс? Как пример проводим 2 документа одновременно. Для примера у них разные склады. Можете подробнее сказать?




ps Кстати допустим 700 пользователей из них пусть 300 активных. В среднем пусть даже по 1 документ в 2 минуты - что врятли... получаем 300/120 - примерно 3 документа в 1 секунду. Причем никто не говорит что они будут еще и одновременными. Вполне вероятно что запрос отработается за 0.1 секунды. (Мы не говорим про типовую зп где и 5 секунд может быть). Тоесть получается что не так уж и часто вобще будут возникать одновременные проведения...

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

ЗЫ блокировка вешается не на время выполнения запроса, а на время существования транзакции. в нашем случае на время проведения документа.

для спящего время бодрствования равносильно сну

ЗЫЫЫ ну и пользователям вы все равно не скажете, что в эту секунду ты можешь проводить документ, а в эту не можешь. поэтому пользователи как правило проводят документы одновременно. в итоге если произошел дедлок, и ресурсы заблокировали друг дружку, то время ожидания 40 секунд дедлока, а за это время еще 120 документов вместе с 120 пользователями накопятся в очередь. в итоге практически все вылетят.

для спящего время бодрствования равносильно сну

RustamZzАлексей2003если регистраторы создаются в одно время, то они находятся рядом, а значит скуль может захватить и соседние записи, потому как по умолчанию происходит блокировка диапазонов (чтобы немного увеличить производительность скуля в случае коротких транзакций, но 1с не дружит с короткими транзакциями).

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