При одновременном пробитии чеков на разных кассах РМК вываливается с ошибкой

1. starget 19.10.15 11:33 Сейчас в теме
1С Розница: Аптека для Украины.
3 кассы работают в терминальной сессии. Фискальные.
Сервер более чем шустрый. Базы на SSD. Тест Гилева выдает 70 очков.

Проблема следующая:
Если одновременно (+/- 1 секунды) кассы пробивают чеки, то они все подвисают на несколько секунд, одна из них, после висяка пробивает и печатает чек, вторая и третья вываливается с ошибкой. Ошибки разные, в 90% случаях одна из касс вывалится с ошибкой блокировки таблиц с чеками, другая с общей ошибкой.
Сами чеки в "документах": первая касса, та которая создает нормально чек и его проводит, отрабатывает на все 100%, по остальным - чека в принципе может не быть; он может быть проведенным но без номера; может быть создан но не проведен.

Понятно, что корень проблемы в блокировках таблиц.

Я вижу такие варианты решения:
1) Не самый лучший. Перевод базы на SQL и запуск управляемых блокировок. Минус этого способа в том, что сама база начинает медленнее работать раза в 2 +/-.

2) Дописать конфигурацию, чтобы при проведении чеков проверялось: проводит ли кто-то сейчас чек или нет, если проводит, то делаем ожидание и становимся в очередь, если очередь свободна, то проводим и печатаем чек.

3) Оптимизация модуля проведения чеков, так как очень много проверок и сам алгоритм проведения не очень удачный - сначала создаем чек, потом проводим, потом печатаем сам чек, потом меняем ему статус на "пробит".

4) Переписали конфигурацию, сначала все действия по проведению чека, потом только печать. Несколько уменьшило количество "сбоев" но не убрало их совсем.

5) Каждая касса своя отдельная база, с "центральной" (операторы, кладовщики, заведующая) и настройка между ними автообмена по расписанию.

Вопрос в том сталкивался ли кто-то с такой проблемой и как оптимальнее ее решить?
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. AlexInqMetal 78 19.10.15 11:57 Сейчас в теме
(1) starget,

вариант дорогой: 1
медленнее работать раза в 2 +/-.
скорее всего дело в неоптимальной настройке сервера

вариант подешевле: 5

применимость остальных вариантов можно только по месту определить. Вариант розницы 2 на sql делал, как раз три кассы - все летало. Вариант с кассовыми узлами на отраслевке делал - тоже как вариант, правда пришлось обмен дописывать так как баги были. В вашем случае РИБ скорее всего будет, так что попроще.
3. starget 19.10.15 12:12 Сейчас в теме
(2) AlexInqMetal,
Вроде должно быть нормально с настройками SQL. 16Гб ОЗУ, i7 4770, SSD SQL, SSD tempdb.
А вторая розница действительно работает шустрее.

У меня на базе первой розницы.
4. Xershi 1533 19.10.15 12:16 Сейчас в теме
(1) starget, читал как Насипов делал управляемые блокировки. Метод интересный, но придется заморачиваться над управляемыми блокировками.
5. Xershi 1533 19.10.15 12:18 Сейчас в теме
(1) starget, еще стоит посмотреть сколько у вас в конфигураторе стоит "Время ожидания до блокировки данных". Возможно увеличение этого параметра часть проблем устранит.
6. and_sk 14 19.10.15 16:46 Сейчас в теме
1.1. минисервер на 5лицензий)
7. starget 19.10.15 18:12 Сейчас в теме
(6) and_sk,
операторы, кладовщики, заведующая

5 пользователей, а остальные куда? в очередь? :)
9. and_sk 14 23.10.15 11:56 Сейчас в теме
(7) starget,
5 пользователей, а остальные куда? в очередь? :)

ну при таком раскладе кассу лучше выделить в отдельную базу,
файловая база - все равно мешать будут друг другу
10. sancho86 1 23.10.15 14:30 Сейчас в теме
(9) and_sk, гигабитные сетевушки + соответствующий свитч и можно еще работать и работать. Тем более на базе первой розницы...
11. starget 24.10.15 18:37 Сейчас в теме
(10) sancho86,
Это личный опыт или теория?
Первый раз слыщу, что сетевая база на 1Гбит/с (какой бы она не была версии) работает лучше и быстрее, чем она-же в RPD сесии на сервере :)
8. starget 19.10.15 18:38 Сейчас в теме
Вопрос решен. Xershi спасибо, 90% решения твой совет.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот