Handling data update/freshness issue in web-app in general (or GWT specifically)

Question

In general, how do you guys handle user update/data freshness interaction with the user (UI issue) in web-apps?

For example:

• Multi-users web-app (like project management)
• Login to a "virtual" space
• People can update project names, etc
• How to handle a situation such that:
  • user-A and user-B load a project with title "Project StackOverflow"
  • user-B updates the title to "Project StackExchange"
  • user-A updates the title after user-B update operation to "Project Basecamp"

The question I'm asking is from the user perspective (UI) and not about transactional operation.

What do most people do in this situation?

• What would you do after user-B updates the title in user-A screen/view?
• What happened when user-A tries to update the title after user-B finished his/her update operation?
  • do you inform user-A that the title has changed and he/she has to reload the page?
  • do you go ahead and change the title and let user-B has old data?
• Do you do some sort of application-level "locking" mechanism? (if someone is updating, nobody else can?)
• Or fix the application workflow? (who has the access to be able to change things, etc).

What would be the simplest solution, but at the same time not annoy the user with more dialog/warning messages.

I've encountered this particular problem frequently in a GWT app specifically where domain models are being passed around and refreshing the whole app/client-side isn't the optimal solution in my mind (since it means the whole "loading"/initialization phase must be executed again in this specific environment).

Maybe the answer is to stay away from GWT? :)

Love to hear options, solutions, and advises from you guys.

Thanks

Answer 1

The general answer to issues of data staleness in a client is either polling, or server push (Comet), depending on how important it is to have up-to-date information.

With polling, your client sends a request for fresh information every N minutes and shows the updated data in the UI (preferably not reloading the whole UI, just parts that have updated).

With server-pushing, your client has a persistent open connection to the server, reconnecting as soon as the connection times out, and whenever the server has new data to tell the client, it does so immediately. This has the advantage of less staleness in the client, but more overhead in total because of all of these persistent connections being made.

Locking is difficult, because it requires a lot of coordination among all parties. The server has to tell the second client to ask for a model that it is locked, then tell it again when it's unlocked, and the client has to know whether it still wants to make a change at all (what if user-A made the same change user-B wanted to make?). In general keeping all clients as up-to-date as is reasonable is the best answer.

To work with your example, after user-A updates a model, the server publishes to anyone who cares that the model has been changed, and user-B's client updates accordingly. Same when user-B updates the model, user-A can tell right away (or after their client polls again).

The rocket-gwt project includes support for Comet, and I've heard good things about it, though I've never tried it myself.

A similar option, though not immediately usable, is HTML5 WebSockets, which removes the need for a persistent connection to the server by opening a specialized direct "channel" between the server and the client. Unfortunately, WebSockets are currently only supported on a small subset of browsers. Hopefully as adoption grows this will be a better option. That being said, if you want to use WebSockets in GWT, I have written some code to do it (shameless self-promotion)