How to keep statefull web clients in sync, when multiple clients are looking at the same data?

Question

In a RIA web client, created with GWT, the state is maintained in the web client, while the server is (almost) stateless (this is the preferred technique to keep the site scalable).

However, if multiple users looking at the same data in their browser and one user changes something, which is send to the server and stored in the database, the other users still have the old data in their browser state. For example a tree is shown and one of the users adds/removes an item from the tree.

Since there can be a lot of state in the client, what is the best technique to keep the state in the clients in sync? Are there any java frameworks that take care of this?

Answer 1

Push changes (delta) only, it applicable, and if not -- re-sync client completely. That's what we do with our remote clients (not only GWT but with Eclipse RCP too). We send delta contexts while changes are small and local, and on global change we re-sync. This will require to design a sophisticated diff protocol, and often will require redesign of remote client protocol from scratch.

Answer 2

The most promising HTTP Push (Comet) library I tried so far is the StreamHub Project:

StreamHub is a highly-scalable HTTP Comet and Reverse Ajax server allowing you to push live data to a web browser without requiring any plugins or security-policy changes. It uses a technique known as Comet or Reverse Ajax to keep a persistent connection open to the browser.

That might be what you are looking for to keep you clients states up to date. They have a GWT adapter project, too.

Answer 3

Comet support is also available in GWT using the rocket-gwt project (which also provides a bunch of other cool features, like lightweight collections, drag-and-drop, etc.) -- Comet is provided by the Remoting package.

Answer 4

I am having the same dilemma on my flex application.

It seems that best way to deal with this is to keep an interval of some seconds between server and client, and force polling the state to each clients.

I have made the following approach, note that this does not solve the out of sync situation, it just reduces significantly the possible situation to happen.

I have at server side, one cache of each collection calls. I have at client side, per instance of application, one cache of that same collections.

Instance one loads some array of objects into a grid. (Builds a collection initial state with the server)

Instance two loads and makes changes, submitting changed data to the server, db info is persisted and server cache is rebuilt. (Client cache also maintains its local cache not requiring to call for the server collection again.)

Instance one is out of sync. (will be in sync at the next polling interval) instance two is sync due to being the app responsible for the changes.

Both instances polls the server from time to time, like a 10 second interval for changes. (If server side cache suffered changes, it will bring the new info to all clients on next interval call.)

If no changes at server side level, no info is sent to one already registered client. (This means no info is exchanged between server and client, reducing overhead.)

If a third client comes in, it's state is fresh and will perform the necessary calls to build its current cache as well.

There is a delay, but it surely helps out propagating changes to the client.

The problem is that the client consumes some extra memory by keeping it's cache state.

I am doing this in a per screen situation, once that screen is out of view, the client cache is nulled, once that screen is called again, local cache is created and the timer starts and the polling begins.

Hope that helps,

Ernani