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

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

Самая многообещающая библиотека HTTP Push (Comet), которую я пробовал, - это StreamHub Project :

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

Возможно, это именно то, что вам нужно, чтобы держать клиентов в курсе последних событий. У них также есть проект GWT-адаптера .

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

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

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

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

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

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

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

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

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

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

Задержка есть, но она, несомненно, помогает распространению изменений на клиента.

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

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

Надеюсь, что это поможет,

Эрнани

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