Одноврем. работа 100 юзеров с одинак.фун-лом

[DA_NEAL]

Резервирование используйте.

[dmites]

Цитата:

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

Резервирование используйте.

А одновременное резервирование не приведет к тем же блокировкам ?

[rmv]

Цитата:

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

А одновременное резервирование не приведет к тем же блокировкам ?

Не думаю если за учет будет отвечать отдельный процесс (NAS) или учет будет происходит по вечерам.
Если все же возникнут проблемы с блокировками с ними гораздо проще бороться нежели с блокировками при учете.
Вплоть до разделения диапазонов Entry No. в Reservation Entry для филиалов (если каждый филиал будет отгружать со своего склада).

[RedFox]

Цитата:

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

Не думаю если за учет будет отвечать отдельный процесс (NAS) или учет будет происходит по вечерам.

Извините, но не понял как разнесенный (отсроченное) учет и резервирование связано?
Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!

Цитата:

Если все же возникнут проблемы с блокировками с ними гораздо проще бороться нежели с блокировками при учете.

Ну возможно вообще создать временную таблицу со строками, связанными с 37, 5740 и просто заносить туда строки с товарами, которые еще можно продавать. И при этом производить сравнение наличия и резерва. А потом уже, отдельным процессом все скопом резервировать..

Можно еще много чего придумать под требования.

Цитата:

Вплоть до разделения диапазонов Entry No. в Reservation Entry для филиалов (если каждый филиал будет отгружать со своего склада).

А зачем разделять там по диапазонам, если там все под Заказы и так разделяется?

[Fordewind]

Цитата:

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

Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!

А вот это уже надо будет проверить. Ведь строки вбиваются по одной и резервируются по одной.

[RedFox]

Цитата:

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

А вот это уже надо будет проверить. Ведь строки вбиваются по одной и резервируются по одной.

Я уже 1 раз проверял и мне достаточно ;-) как по мне - не учень приятное зрелище. И особенно когда вокруг тебя куча "веселых" Торговых.
Если хотите, то можете организовать "показательные работы". Заодно может и поделитесь Вашей статистикой.

Цитата:

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

При учете резервы снимаются. Подозреваю что не без LockTable. Но даже если и без - Locktable на резервировании будет мешать снятие резервов. Вывод - при одновременном учете и резервировании вероятность блокировать увеличивается.

Согласен, что при учете БУДУТ блокировки. Но я имел ввиду блокировки еще те блокировки, когда пользовать еще только набирает Заказ. Удаление из 337 таблицы будет "быстрее", чем "вставка".

Цитата:

Если правильно понял Вы предлагаете использовать temporary table...

К сожалению, Вы не правильно меня поняли. Я имел ввиду именно временную таблицу для занесения строк резерва, а не Свойство Таблицы = Temporary. И проверка тут на 100% покрытие (НЕ резервирование) и на сравнение по наличному кол-ву в системе на текущий момент.
Да и идея была за 5 минут ;-) Если нужен 100% работоспособный быстро-модифицируемый оптимизированный механизм - это другое совсем дело! Там не только 1 таблица, но еще несколько полей в другой

Кстати, при желании можно залезть в не системную таблицу средствами SQL и вставка 1 строки в незагруженную таблицу будет быстрее, чем дополнительное прочтение (кстати, опять с блокировками) из другой (будет JOIN)

Цитата:

... У каждого филиала 337 таблица будет залочена только в своем диапазоне ...

Идея очень хорошая, но она все равно приводит к блокировкам записей в таблице, которых я бы не стал делать..
Но советую еще кроме таких изменений зайти в SSProfiler+DTA и поотпимизировать. + Чтобы не вылазить за диапазон, изменять периодически номера в данной таблице (иначе можно не угадать с размерность диапазона).

[rmv]

Цитата:

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

Извините, но не понял как разнесенный (отсроченное) учет и резервирование связано?
Вот именно, - когда начнут все эти 100 пользователей колбасить заказы, то мы просто получил залоченную 337 таблицу!

При учете резервы снимаются. Подозреваю что не без LockTable.
Но даже если и без - Locktable на резервировании будет мешать снятие резервов. Вывод - при одновременном учете и резервировании
вероятность блокировать увеличивается.

Цитата:

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

Ну возможно вообще создать временную таблицу со строками, связанными с 37, 5740 и просто заносить туда строки с товарами,
которые еще можно продавать. И при этом производить сравнение наличия и резерва.
А потом уже, отдельным процессом все скопом резервировать..
Можно еще много чего придумать под требования.

Если правильно понял Вы предлагаете использовать temporary table.
Интересное решение . Яблок конечно всем хватит.. но токо до момента учета .
Или есть способ юзеру залесть во временную таблицу другого юзера?
В противном случае чем Ваше предложение отличается 32 таблицы (Positive=true - товар которые еще можно продавать)
+ 337 - резервы на эти товары?


[quote=RedFox;364169]
А зачем разделять там по диапазонам, если там все под Заказы и так разделяется?
[quote=RedFox;364169]

К сожалению (или счастью?) номера документа не включен в PK 337 таблицы.
Напоминаю тему обсуждения - уменьшить вероятность блокировок.
Поясняю свою мысль:
1. Принимаем решение - разделяем 337 на диапазоны по филиалам
А - 0..1000000
Б - 10000000..20000000

2. Везде в резервировании заменяем код поиска последнего Entry No. с одновременной блокировкой таблицы
(LockTable; Find('+); )
на примерно след.
(setfilter("Entry No.", GetFilialFilter); :Locktable; Find('+'));

Что получили
А и Б одновременно резервируют
A:
setfilter(0..1000000);
find('+');
последняя запись 300 (только ее и (или) на Сиквеле экстент залочит сервер)

Б:
setfilter(1000000..2000000);
find('+');
последняя запись 10000500 (только ее и (или) на Сиквеле экстент залочит сервер)
А и Б мешать друг другу не будут.
Заметьте - другие пользователи из филиалов буду ждать освобождения своих диапазонов.

Вывод:
У каждого филиала 337 таблица будет залочена только в своем диапазоне (кроме случаев когда последние записи 2 филиалов будут
в одном экстенте - такое будет только при небольшом числе записей в 337, обойти можно также вставив пустышки)
и возможно одновременное резервирование

Ремарка про склад - locktable все же хорошая функция, позволяет не зарезервировать 2 раза один и тот же товар.