views:

145

answers:

4

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?

+1  A: 

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.

Slava Nadvorny
A: 

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.

Daff
StreamHub is partial a commercial product (free basic version) and they have no pricing on their site, which always give me a bad feeling, read expensive.
Hilbrand
A: 

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.

Jason Hall
Comet is only the technique to communicate 'real-time' between client and server, but doesn't help with keeping multiple clients in sync. Or did I miss something?
Hilbrand
If the server and clients have a "real-time" view of eachother, when the server gets notified of one client's change, it can publish that change to all other clients immediately.As for techniques for what exactly to push, I'd probably have incremental changes pushed to each client, and also have a periodic job to make sure everything is synced, like every 10 minutes a fuller picture of state is pushed to each client to make sure everything's still okay.And make sure that your server can notice and be resilient to changes made to an object by two clients, in case things do get out of sync.
Jason Hall
A: 

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

Ernani Joppert