Обмен мобильного приложения с центральной базой через план обмена
Мобильное приложение платформа 8.3.9.74
Обмен с центральной базой через web-сервис, регистрация изменений через план обмена - Центральный узел и множество узлов для каждого мобильного устройства. Моб. приложение установлено на 100 устройствах, каждое из них обращается к плану обмена для выгрузки и загрузки данных примерно каждые 5-10 минут. В результате на каждом втором устройстве обмен заканчивается ошибкой "Конфликт блокировок при выполнении транзакции", обмен не производится. Подскажите, пожалуйста, как можно более оптимально организовать обмен в данном случае? Просто изначально не предполагалось использование такого большого количества устройств, думали, их будет около десятка, и при тестировании таких проблем не было, сейчас же, спустя год работы приложения, надо эту сложность устранить малой кровью. Спасибо
Обмен с центральной базой через web-сервис, регистрация изменений через план обмена - Центральный узел и множество узлов для каждого мобильного устройства. Моб. приложение установлено на 100 устройствах, каждое из них обращается к плану обмена для выгрузки и загрузки данных примерно каждые 5-10 минут. В результате на каждом втором устройстве обмен заканчивается ошибкой "Конфликт блокировок при выполнении транзакции", обмен не производится. Подскажите, пожалуйста, как можно более оптимально организовать обмен в данном случае? Просто изначально не предполагалось использование такого большого количества устройств, думали, их будет около десятка, и при тестировании таких проблем не было, сейчас же, спустя год работы приложения, надо эту сложность устранить малой кровью. Спасибо
Ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Очевидно, блокировка происходит при выгрузке изменений из ЦУ в МУ (при чтении изменений из плана обмена). При записи изменений МУ - ЦУ блокируется только текущий записываемый объект, при чтении - все таблицы изменений.
Таким образом, нужно минимизировать время блокировки при чтении изменений в ЦУ. Прочитать изменения в переменную (например, хранилище значений) - снять блокировку - начать выгрузку данных из хранилища в МУ (длительный процесс).
Порядок действий в ЦУ должен быть такой (так приводится в демо-примерах):
1. Получение данных из МУ.
2. Выгрузка данных в МУ.
Посмотрите, не поменяли ли вы их местами. Нет ли в начале процедуры чтения данных из плана обмена, вызывающего блокировки, которые сохраняются до конца транзакции.
Таким образом, нужно минимизировать время блокировки при чтении изменений в ЦУ. Прочитать изменения в переменную (например, хранилище значений) - снять блокировку - начать выгрузку данных из хранилища в МУ (длительный процесс).
Порядок действий в ЦУ должен быть такой (так приводится в демо-примерах):
1. Получение данных из МУ.
2. Выгрузка данных в МУ.
Посмотрите, не поменяли ли вы их местами. Нет ли в начале процедуры чтения данных из плана обмена, вызывающего блокировки, которые сохраняются до конца транзакции.
(2) Порядок проверила - там все верно. Судя по наблюдению за процессом обмена - одновременно обменяться пытаются около 5-10 устройств, они неизбежно вызывают блокировки... Пока я вижу только два выхода - 1) Переписывать все в обход плана обмена, 2) Переводить все в фоновый режим без вывода ошибок - когда-нибудь да обменяется, а ошибки не будут нервировать пользователей
(3) Можно попробовать сделать так:
В ЦУ запустить фоновое задание, которое раз в 10 минут формирует пакет выгрузки для всех узлов. Чтобы исключить "мертвые" узлы, можно анализировать дату/время последнего получения данных от них. Фоновое задание формирует пакет выгрузки и помещает его в регистр сведений с измерением "УзелОбмена".
МУ при обращении к ЦУ, берет данные для выгрузки из этого регистра сведений, не читая данные из плана обмена.
Тут может быть опасность, что фоновое задание будет без перерыва выгружать данные и, соответственно, постоянно блокировать план обмена, так что никто не сможет в него ничего записать.
В ЦУ запустить фоновое задание, которое раз в 10 минут формирует пакет выгрузки для всех узлов. Чтобы исключить "мертвые" узлы, можно анализировать дату/время последнего получения данных от них. Фоновое задание формирует пакет выгрузки и помещает его в регистр сведений с измерением "УзелОбмена".
МУ при обращении к ЦУ, берет данные для выгрузки из этого регистра сведений, не читая данные из плана обмена.
Тут может быть опасность, что фоновое задание будет без перерыва выгружать данные и, соответственно, постоянно блокировать план обмена, так что никто не сможет в него ничего записать.
Вот за такие посты реально обидно :( Ты тут всем по 100500 раз рассказываешь, на курсах, в статьях, на конференциях, и все-равно одно и тоже :)
Все просто. НЕ НАДО ДЕЛАТЬ ХОЛОСТЫЕ ВЫЗОВЫ!!! ЗАБУДЬТЕ!!! АУ!!! Мобильная, это не стационарная. У вас есть ID мобильного устрйоства, по нему вы можете послать уведомление.
Итого, весь процес выглядит так:
1. План обмена с фиксированными изменениями, у каждого узла есть реквизит ID пуш сообщения
2. Регламент, который получает факт наличия изменения и высылает приглашение на обновление 2-3 клиентам.
3. Мобильники получив пуш или сразу обновляются, или позже, если сейчас не в 1с.
4. Радуемся жизни.
Можно усложнить - регламент сам делает выгрузки для мобильных в фоне, и мобильная потом их забирает, и ложет туда потом свой обмен. Но это очень архи сложно, ибо слишком много переменных, контроль ошибок, версионность и прочая лабуда.
З.Ы. Накипело, стабильно раз в неделю получаю такого рода вопросы :)
Все просто. НЕ НАДО ДЕЛАТЬ ХОЛОСТЫЕ ВЫЗОВЫ!!! ЗАБУДЬТЕ!!! АУ!!! Мобильная, это не стационарная. У вас есть ID мобильного устрйоства, по нему вы можете послать уведомление.
Итого, весь процес выглядит так:
1. План обмена с фиксированными изменениями, у каждого узла есть реквизит ID пуш сообщения
2. Регламент, который получает факт наличия изменения и высылает приглашение на обновление 2-3 клиентам.
3. Мобильники получив пуш или сразу обновляются, или позже, если сейчас не в 1с.
4. Радуемся жизни.
Можно усложнить - регламент сам делает выгрузки для мобильных в фоне, и мобильная потом их забирает, и ложет туда потом свой обмен. Но это очень архи сложно, ибо слишком много переменных, контроль ошибок, версионность и прочая лабуда.
З.Ы. Накипело, стабильно раз в неделю получаю такого рода вопросы :)
(6) Спасибо!
Но у меня МУ инициируют обмен в тот момент, когда на них появляются данные для передачи. И заодно забирают зарегистрированные для них измененные данные. С большим количеством МУ неизбежны блокировки при использовании плана обмена. Или я Вас неправильно понимаю...
Но у меня МУ инициируют обмен в тот момент, когда на них появляются данные для передачи. И заодно забирают зарегистрированные для них измененные данные. С большим количеством МУ неизбежны блокировки при использовании плана обмена. Или я Вас неправильно понимаю...
Проблема в том, обмен может происходить только с одним узлом за раз, так как при обмене блокируется вся таблица изменений. Тут несколько вариантов:
1. Отправлять изменения чаще и маленькими порциями в рамках одного плана обмена.
2. Добавить несколько планов обмена - например один для справочников, другой для документов и регистров.
И конечно, перепишите на http сервис, говорят он работает быстрее чем web-сервис.
А вообще следует провести замеры времени при загрузке обычного пакета от МУ. Обычно размер данных от МУ довольно небольшой, объем измененных данных тоже, соответственно скорость загрузки их должна быть высокой. Как вариант - при загрузке из МУ отключить все возможные проверки и отключить проведение по регистрам (все то, что требует времени при записи).
1. Отправлять изменения чаще и маленькими порциями в рамках одного плана обмена.
2. Добавить несколько планов обмена - например один для справочников, другой для документов и регистров.
И конечно, перепишите на http сервис, говорят он работает быстрее чем web-сервис.
А вообще следует провести замеры времени при загрузке обычного пакета от МУ. Обычно размер данных от МУ довольно небольшой, объем измененных данных тоже, соответственно скорость загрузки их должна быть высокой. Как вариант - при загрузке из МУ отключить все возможные проверки и отключить проведение по регистрам (все то, что требует времени при записи).
В продолжение темы. Прошу не ругать, потому что приложение уже второй год работает, сотня одновременно работающих и обменивающихся планшетов. И при этом нельзя кардинально ничего менять, потому что при обновлении необходимо обеспечить возможность одновременной работы как старой, так и новой версии.
Я сделала следующим образом:
1) убрала ручной обмен - перевела все в фоновый режим
2) убрала авторегистрацию объектов, записываю измененные объекты в регистр
3) фоновым заданием из этого регистра регистрирую изменения в плане обмена, данные регистра удаляю. Следом инициирую обмен с центральной базой.
При этом пользователи продолжают работать на планшетах - делают документы и записи регистра с фотографиями.
По большей части приложение в целом и обмен работают корректно. До тех пор, пока в процессе обмена приложение не в центральной базе не столкнется с тем, что план обмена занят другим узлом. При этом фоновое задание завершается аварийно и по какой то причине блокирует таблицу config, потому что при попытке сделать что либо в этот момент в приложении выдается ошибка: конфликт блокировок при выполнении транзакции - не удалось заблокировать таблицу config. Помогите, пожалуйста, вторую неделю сижу с этой проблемой уже... Спасибо!
Я сделала следующим образом:
1) убрала ручной обмен - перевела все в фоновый режим
2) убрала авторегистрацию объектов, записываю измененные объекты в регистр
3) фоновым заданием из этого регистра регистрирую изменения в плане обмена, данные регистра удаляю. Следом инициирую обмен с центральной базой.
При этом пользователи продолжают работать на планшетах - делают документы и записи регистра с фотографиями.
По большей части приложение в целом и обмен работают корректно. До тех пор, пока в процессе обмена приложение не в центральной базе не столкнется с тем, что план обмена занят другим узлом. При этом фоновое задание завершается аварийно и по какой то причине блокирует таблицу config, потому что при попытке сделать что либо в этот момент в приложении выдается ошибка: конфликт блокировок при выполнении транзакции - не удалось заблокировать таблицу config. Помогите, пожалуйста, вторую неделю сижу с этой проблемой уже... Спасибо!
(10)Спасибо за ответ. Как показала практика, вылет программы и ошибки про конфликт блокировок и таблицу cinfig возникают в том случае, когда фоновое задание завершено аварийно. В моем случае фоновое задание - это обмен через веб-сервис. Если произошла ошибка при выполнении операции веб-сервиса. Я исключила возможные ошибки при выполнении операций веб-сервиса, но я не могу исключить ошибку, когда превышено время ожидания подключения к веб-сервису. Например, когда планшет отправляет запрос на подключение на сервер, а там уже висят в ожидании 10 пользователей. В таком случае ошибка все равно возникает. Как результат - приложение вылетает с ошибкой снова, хоть это и произошло в фоне. На стационарной платформе, конечно же, вылета не происходит в таких случаях. И как бы я не старалась свести к минимуму ошибки операций веб-сервиса, в некоторых случаях они неизбежны, и поэтому неизбежен вылет приложения. Поэтому на мой взгляд тут либо закрывать глаза на эту ошибку и просто перезапускать приложение, что совсем не комильфо... Либо переводить пользователей на ручной обмен, и придумать механизм, как заставить их производить обмен как можно чаще, чтобы избежать большого размера пакета при обмене
Либо переводить пользователей на ручной обмен, и придумать механизм, как заставить их производить обмен как можно чаще, чтобы избежать большого размера пакета при обмене
А пакеты анализировали? В них точно ничего лишнего? Может там какие нибудь объекты регистрируются которые регистрироваться не должны.
Например один талантливый парень написал загрузку Номенклатуры из одной базы в базу с РИБ на очень много узлов. И ничего лучше не придумал как обновлять все 10000 номенклатурных позиций при загрузке. А из них изменялись за весь период может всего 100-150 номенклатурных позиций. Но каждый раз в обмен регистрировались все 10 тыс. Которые потом расходились по узлам. И обмен между узлами из за этого шёл по 10-20 минут.