Исходные данные. Есть база 1с 7.7, файловая. Работают около 100 пользователей. Иногда начинаются дикие блокировки на транзакциях.
Вопрос 1. Время ожидания захвата таблиц стоит 15 сек. Если его установить поменьше (3-5 сек), может это улучшить жизнь? То есть, вроде транзакции быстрее должны отваливаться, не будет скапливаться очередь.
Вопрос 2. Где и как поменять всем пользователям это время ожидания?

уменьшив время - юзеры быстрее будут получать сообщение о блокировке
ищи изделие romix-а, забыл как зовется ((
vk_sleep мб

(1) спасибо, поищу.
просто временами в журнале регистрации цепочка ошибок ожидания на транзакциях с интервалом в 0-20 сек. может, они уже друг за друга цепляются, и если ошибочные быстрее отваливаться будут, будет меньше таких цепочек? или бред несу?

(2) 1cv7.cfg

(0)
0

(0)Только надо не уменьшать, а увеличивать.

(5) Это чтоб сервак положить?

Лучше даже так:

1. 0
2. либо править всем cfg, либо вк, хоть от trad для управления настройками, хоть вк приоритетс

У 1С блокировки реализованы через периодический запрос блокировки определённого файла, то есть когда несколько сеансов просят блокировку, то они выполняют попытку блокировки файла (и по умолчанию без таймаута).
Соответственно, никакой очереди блокировок нет, то есть успевает тот, кто первый попадёт в момент освобождения.
Конечно, переписать систему блокировок нереально, но можно все долгоиграющие действия вынести в отдельный "серверный" сеанс и только давать ему команды - тогда столкновения на выполнении действий удастся избежать (но придётся переписывать логику программы - так как сервер не может провести документ, если он открыт у клиента).

надо перейти на v8, там все не так страшно.

(8) система блокировок давно переписана ромиксом.
Можно переписать иначе, исходники у него открыты.

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

(10) Она там не сильно переписана - там вставили время ожидания захвата и освобождение процессора (Sleep).
Сама идея никуда не делась, так как все процессы 1С равноправны и сделать менеджер не получится.
Есть другая реализация сетевого доступа на основе сервера CodeBase - там есть сервер, но насколько это надёжно будет работать - это отдельный вопрос.

что за чудо конфигурация, выдерживающая 100юзеров в дбф ? или вы ее обрезаете каждый месяц ? или в хлам переписанная на прямые запросы ?

(13) у нас такая. режем раз в год, прямые запросы не используем (так балуемся во внешних отчетах, но в основной конфиги их нет)

А что 100 пользователей там делают ?
Если они просто будут документы вводить база будет тормозить даже от нажатия INS.
Хотя, если они просто "сидят" в базе, ничего не делая, то может и работать.

(12) а много и не надо. Достаточно что загрузка ожидающих процессов становится равной нулю.

(15) у меня сто пользователей вводят документы. И ничего не тормозит.

правда естественно не дбф.

(16) Одно дело, когда тормозит, а другое дело, когда транзакции отваливаются. Торможение, патч 1С снимает, а вот проблему оптимальности блокировки можно решить только на уровне фильтрующего драйвера файловой системы, где можно перехватить запрос на блокировку и поставить его в очередь на определённое время, пока не освободиться другой процесс.
Но это уже серьёзное системное программирование, а не перехват DLL.
Зато можно сделать так, чтобы все получали право на запись в порядке очереди, а не в случайном порядке, как реализовано в 1С.
(18) Можно и dbf, если использовать не встроенный алгоритм 1С, а доступ к файлам через ADO и т.п.

(0) У меня 50 пользователей в терминале (база ДБФ примерно 6 ГБ) и вроде оибок блокировок нет, правда я использую кернел33 и кернел37 и у меня новый достаточно мощный сервер хотя в период перехода на новый сервер база несколько дней работала на стареньком компе- недосервере. Да еще бухгалтерия там работала. И ничего, конечно, транзакции порой отваливались, но цепной реакции не было

(19) на Исе hogik mo;tn просветить по этому вопросу. он движок глубоко копал.