Всем привет!

Есть следующая задача:

Есть БД сервер, в котором хранятся данные с набором правил по формирования, допустим цен на товары.
Существует много клиентов которые соединяются с этим БД сервером и каждый забирает свой набор правил.

У каждого клиента(заказчика) устанавливается центральный сервер(приложение на Java + H2 Embedded DB), которое хранит в себе этот набор правил.
На каждом рабочем месте клиента(заказчика), устанавливается клиентское приложение(API, Java + H2 Embedded DB), которое хранит в себе этот же набор правил по формированию цен и постоянно синхронизируется с центральным сервером.
Задача клиентского приложения, получить ID товара, "пропустить" через все правила и вернуть требуемую цену.

Вопрос следующий...
Как лучше всего организовать синхронизацию между центральным сервером заказчика и его клиентскими приложениями, с учетом того что правила сформированные на центральном сервере должны как можно быстрее попасть клиенту(API)?
Клиентское приложение, не всегда будет online с центральным сервером(даже не будет работать). И в момент его включения, все данные сформированые за время его отсутствия, должны ему попасть в H2 DB.

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

Возможно есть другие варианты синхронизации? Может я ошибаюсь по поводу JMS?

Как вариант замены JMS, рассматриваю HTTP сервер(Embedded Jetty), к которому соединяются клиенты(long polling) и работают по похожему принцыпу как и с JMS, только контроль отправленых данных клиенту я веду самостоятельно в H2 DB.

Что Вы думаете об этом подходе? Насколько он правильный? Была ли у Вас практика работы с таким подходом?



Что скажете по поводу H2 как embedded базы данных? Мои тесты показываю хорошие результаты, только в продакшене никогда не использовал.

Заранее благодарен за помощь!

BlazkowiczНа сколько большая база? Имеет ли смысл тупо реплицировать все изменения с центальной базы на локальные?

Не большая. Порядка 200000 позиций и 100-500 сложных схем правил обработки.
BlazkowiczУ нас похожая схема, но у нас очень много бизнес-логики завязано на синхронизацию Поэтому пилим свой движок.
А что за движок? Могли бы Вы описать по подробнее?
BlazkowiczНо если нужна не сложная репликация то есть opensource решения даже для JDBC.
Можете привести пример?

Скажите пожалуйста, на сколько корректно делать репликация в случае если клиентов будет порядка 100-500(в зависимости от заказчика)?

Моей основной целью является понять как передать клиентам список изменений, с учетом что каждый из них может получить их в разное время.
По сути, данные у всех клиентов будут одинаковые. Вариант с репликацией кажется самым простым, но меня смущает что репликация будет работать на большое кол-во баз(как я уже говорил 100-500). Как она себя поведет, да и еще и H2 DB, не понятно.

Помимо этого, очень хотелось бы что бы сессии каждого клиента не висели на сервере, дабы не перегружать его лишний раз.

Как вариант, организовать что-то типа svn'а:
На главном сервере формируется таблица(триггерами) ревизий изменений, с сылками на таблицы и их ID.
У клиента прямой доступ к базе главного сервера и он проверяет только эту таблицу, с учетом того что он хранит у себя идентификатор последней загруженной ревизии.
В случае если ревизии разные на сервере и клиенте, клиент выгружает список изменений, формирует набор запроссов и отправлет на сервер.

Что думаете?

P.S. обратная связь от клиентов к серверу будет. Они будут писать что-то типа лога, в котором будет указана какое из правил было применено и при каких условиях.