Стратегия автономной/онлайн-синхронизации данных

Мое требование: у меня есть веб-приложение J2EE для сервера и клиентское J2EE-приложение. Иногда клиент может отключиться. Когда клиент приходит в сеть, он должен иметь возможность синхронизировать изменения туда и обратно. Также я должен иметь возможность контролировать, какие строки/таблицы нужно синхронизировать на основе некоторых фильтров/правил. Есть ли какие-либо существующие рамки Java для этого? Если мне нужно реализовать самостоятельно, каковы различные стратегии, которые вы можете предложить?

Одним из моих решений является поддержка SQL-журналов и выполнение тех же операторов с другой стороны во время синхронизации. Вы видите какие-либо проблемы с этой стратегией?

Ответ 1

Существует ряд библиотек Java для синхронизации данных/репликации. Два, о которых я знаю, daffodil и SymmetricDS. В предыдущей жизни я глупо реализовал (на Java) свой собственный процесс репликации данных. Это похоже на то, что должно быть довольно простым, но если данные могут обновляться одновременно в нескольких местах, это адски усложняется. Я настоятельно рекомендую вам использовать один из вышеупомянутых проектов, чтобы попытаться обойти эту сложность самостоятельно.

Ответ 2

Проблема biggist с синхронизацией - это когда пользователь редактирует что-то в автономном режиме, и он редактируется онлайн одновременно. Вам необходимо объединить две измененные части данных или обработать пользовательский интерфейс, чтобы пользователь мог сказать, какая версия верна. Если вы исключите возможность редактирования одновременно, то вам не придется решать эту проблему.

Обычно метод добавляет поле "изменено" ко всем таблицам и сравнивает измененное клиентом поле для данной записи в заданной строке с датой изменения сервера. Если они не совпадают, вы заменяете данные сервера.

Будьте осторожны с автогенерированными ключами - вам необходимо убедиться, что целостность данных сохраняется при копировании с клиента на сервер. Строгое выполнение SQL-запросов на сервере может привести вас к ситуации, когда ключ с автогенерированием изменился, и внезапно ваши внешние ключи указывают на разные записи, чем вы планировали.

Часто при импорте данных из другого источника вы отслеживаете первичный ключ от внешнего источника, а также свой собственный первичный ключ. Это упрощает определение изменений и различий между наборами данных для сложных ситуаций синхронизации.

Ответ 3

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

Ответ 4

Что лучше всего подходит в качестве хранилища данных на стороне клиента в вашем приложении? Вы можете выбрать из встроенной базы данных, такой как SQLite или очередь сообщений, или некоторое хранилище объектов или (если ни одно из них не может использоваться, поскольку это веб-приложение) файлы/документы, сохраненные на клиенте с использованием веб-базы данных или IndexedDB через HTML 5 LocalStorage.

Проверьте бумагу Золотая лихорадка: промежуточное ПО для мобильных транзакций с Java -Объектная репликация. Документация Microsoft о периодически подключаемых системах описывает два подхода: ориентированные на обслуживание или ориентированные на сообщения и ориентированные на данные. "Золотая лихорадка" использует более ранний подход. В более позднем подходе используется слияние репликации данных.