Динамическая подмена шейп файла

Question

Здравствуйте!
Есть такая задача: подменять раз в 3 часа шейп файлы для веб-сервиса. Скажите, пожалуйста, если мы заменим шейп файл для динамического веб сервиса во время его работы, то как это скажется на его работе и в какой момент произойдут изменения в отображаемых данных? Возможно ли при этом возникновение ошибок и как их избежать? Клиент на Flex.

Answer 1

Звучит рискованно.
Нельзя вместо шейп-файлов вести данные в SDE и этому же источнику подключить и сервис?

Answer 2

Можно, тогда встает вопрос как автоматизировать замену данных в SDE? Существует ли механизм для автоматического импорта? Данные в SDE можно положить только из шейпов, т.к. других источников нет.

Answer 3

Не, я хотел предложить именно вести слои в SDE, а не в шейпах. Вопрос синхронизации бы снялся.

Наверное надо останавливать сервис, менять данные и перезапускать сервис. Но не торопитесь, наверное специалисты ещё подскажут.

Answer 4

Можно всё.

Я так понимаю проблему - есть входящие шейпы, от (неважно откуда) скажем так, периферии. Вам нужно автоматически актуализировать данные?

Если да, скажите какой объем поступающих данных (примерно), сколько (примерно) источников. Актуализация я так понимаю не реже 3еёх часов, или нужно (хочеться) псевдо-реал-тайм?

Answer 5

Источник один, слоев  порядка 10 (суммарный размер шейпов не более 50 мб). Да, актуализация каждые 3 часа, чаще вряд ли.

Answer 6

Источник один, слоев порядка 10 (суммарный размер шейпов не более 50 мб). Да, актуализация каждые 3 часа, чаще вряд ли.

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

Answer 7

Источник один, слоев порядка 10 (суммарный размер шейпов не более 50 мб). Да, актуализация каждые 3 часа, чаще вряд ли.

Можно сделать так.
Вариант "сельский":
Фоновая служба которая сканирует входной каталог.
По приходу файлов - загрузка через sdeimpot в соответствующие таблицы определение куда грузить - по названию входных файлов. При успешной загрузке - удаляем файлы. При неуспехе - попытка номер 2, неуспех - переносим файлы в папку "брак".

Плюсы:
Простота реализации.
Не нужно ничего оптимизировать - скорость псевдомаксимальная.

Минусы:
Никакой дополнительной обработки входящих данных.
Количество типов данных и их имена жёстко прописано в фоновой службе, добавление нового типа.
Останов/фейл фоновой службы - кто-то страдает.
Всё происходит в одном потоке (количество ядер и процессоров не влияет на скорость, фактически влияет только скорость одного, используемого ядра).


Вариант "сельский +":
Тоже самое, но имена и  типы хранятся в ini файле, и считываются перед сканированием директории.

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

Минусы:
Никакой дополнительной обработки входящих данных.
Останов/фейл фоновой службы - кто-то страдает.
Всё происходит в одном потоке.

Вариант "для пацанофф":
Фоновая служба берёт настройки из ini файла, если в директории есть какие-либо файлы она объявляет COM+ событие на которое реагируют загрузчики. Которые тоже сканируют директорию и ищут необходимый (прописаный в ини) файл. Читают его и записывают в ГБД.

Плюсы:
- Модульность - фейл одного загрузчика или фоновой службы ни на что не влияет. При фейле службы система сама в состоянии её перезапустить.
- Ресурсы системы используються максимально, чем больше ядер и процессоров - тем больше может быть загрузчиков.
- При загрузке данные можно обрабатывать - высчитывать поля, геометрию,  и вообще извращаться как угодно.
- Система масштабируеться без остановок фоновой службы (и тем более её перекомпиляции), и вообще чего либо. Каждый модуль подключается отдельно, независимо от других.

Минусы:
- Скорость во многом зависит от кривости рук написавших код загрузчика.
- немного сложновато.

Вариант "для продвинутых пацанофф":
Тоже самое что и предыдущий вариант, только при загрузке используеться режим "только загрузка", и эксклюзивная схема доступа. Плюс ко всему есть возможность хранить ГИУД загрузчика и машину исполнения для вызова DCOM подписчиков и подписчиков "вне очереди исполнения".

Плюсы:
- всё выше перечисленное.
- Максимальная скорость загрузки (на уровне обычного SQL insert'a), возможность постройки систем загрузки на базе Блейд-систем (за счёт распределённых DCOM загрузчиков).

Минусы:
-Ну чтож, довольно сложная система =)))