У меня та же самая дилемма в моем приложении Flex.
Похоже, что лучший способ справиться с этим - сохранить интервал в несколько секунд между сервером и клиентом и принудительно опросить состояние для каждого клиента.
Я сделал следующий подход, обратите внимание, что это не решает ситуацию несинхронизации, а просто значительно уменьшает возможную ситуацию.
У меня на стороне сервера один кеш каждой коллекции вызовов.
У меня на стороне клиента есть один кеш из тех же коллекций.
Экземпляр один загружает некоторый массив объектов в сетку. (Создает начальное состояние коллекции с сервером)
Экземпляр два загружает и вносит изменения, отправляя измененные данные на сервер, информация о БД сохраняется и кэш сервера перестраивается.
(Клиентский кеш также поддерживает свой локальный кеш, не требуя повторного вызова коллекции серверов.)
Экземпляр один не синхронизирован. (будет синхронизирован на следующем интервале опроса)
Второй экземпляр синхронизирован, поскольку приложение отвечает за изменения.
Оба экземпляра время от времени опрашивают сервер, как 10-секундный интервал для изменений.
(Если в кеше на стороне сервера произошли изменения, новая информация будет передана всем клиентам при следующем интервальном вызове.)
Если никаких изменений на уровне сервера не происходит, информация не отправляется одному уже зарегистрированному клиенту.
(Это означает, что между сервером и клиентом не осуществляется обмен информацией, что снижает накладные расходы.)
Если заходит третий клиент, его состояние свежее и он также будет выполнять необходимые вызовы для создания своего текущего кэша.
Существует задержка, но она, безусловно, помогает распространять изменения на клиенте.
Проблема в том, что клиент потребляет дополнительную память, сохраняя состояние своего кэша.
Я делаю это в за экран , , когда этот экран не виден , кэш клиента обнуляется , после повторного вызова этого экрана , создается локальный кэш, запускается таймер и начинается опрос.
Надеюсь, это поможет,
Эрнани