Как сохранить синхронизированные веб-клиенты в синхронизации, когда несколько клиентов ищут одни и те же данные?

Question

В веб-клиенте RIA, созданном с помощью GWT, состояние поддерживается в веб-клиенте, а сервер (почти) без гражданства (это предпочтительный метод, позволяющий масштабировать сайт).

Однако, если несколько пользователей, просматривающих одни и те же данные в своем браузере и один пользователь, что-то изменят, которые отправляются на сервер и хранятся в базе данных, другие пользователи по-прежнему имеют старые данные в своем браузере. Например, показано дерево, и один из пользователей добавляет/удаляет элемент из дерева.

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

Answer 1

Только изменения (только дельта), это применимо, а если нет - повторная синхронизация клиента полностью. Это то, что мы делаем с нашими удаленными клиентами (не только GWT, но и Eclipse RCP). Мы отправляем контексты дельты, а изменения - небольшие и локальные, а при глобальном изменении мы повторно синхронизируем. Это потребует разработки сложного протокола diff и часто потребует редизайн удаленного клиентского протокола с нуля.

Answer 2

Наиболее перспективным HTTP Нажмите (Comet) библиотеки я пытался до сих пор является StreamHub Project:

StreamHub является сервером высоко масштабируемое HTTP Comet и Reverse Ajax позволяет вас нажать данных в реальном времени в Интернете браузер без каких-либо плагинов или изменений политики безопасности. Он использует технику , известную как Comet или Reverse. Ajax для сохранения постоянного соединения открыт для браузера.

Это может быть то, что вы ищете, чтобы держать вас в курсе состояния клиентов. У них также есть проект GWT adapter.

Answer 3

Поддержка Comet также доступна в GWT с использованием проекта rocket-gwt (который также предоставляет множество других интересных функций, таких как легкие коллекции, перетаскивание и т. Д.). Комета предоставляется пакетом Remoting.

Answer 4

У меня такая же дилемма в моем приложении flex.

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

Я сделал следующий подход, обратите внимание, что это не решает проблему синхронизации, она просто значительно снижает возможную ситуацию.

У меня есть на стороне сервера, по одному кешу каждой коллекции вызовов. У меня на стороне клиента, на экземпляр приложения, один кеш из тех же коллекций.

Экземпляр 1 загружает некоторый массив объектов в сетку. (Создает исходное состояние коллекции с сервером)

Экземпляр 2 загружает и вносит изменения, отправляет измененные данные на сервер, информация db сохраняется и серверный кеш перестраивается. (Кэш клиента также поддерживает свой локальный кеш, не требующий повторного вызова коллекции сервера.)

Экземпляры не синхронизированы. (будет синхронизироваться в следующем интервале опроса) экземпляр two - это синхронизация из-за того, что приложение отвечает за изменения.

Оба экземпляра периодически проверяют сервер, как 10-секундный интервал для изменений. (Если на стороне сервера кэш пострадал изменения, он принесет новую информацию для всех клиентов на следующем интервале вызова.)

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

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

Существует задержка, но она, несомненно, помогает распространять изменения клиенту.

Проблема заключается в том, что клиент потребляет дополнительную память, сохраняя ее состояние кеша.

Я делаю это в на экран ситуации, раз, что экран находится вне поля зрения, кэша клиента обнуляется, раз, что экран вызывается снова, местной создается кеш и начинается таймер, и начинается опрос.

Надежда, что помогает,

Эрнани