In a web application that has a significant ajax component, where is the best place for the client-side concurrency responsibility to lie?

We're trying to use MVC on both the server application (LAMP stack) and the client application (ajax, mostly jQuery and unobtrusive js).

On the server-side, our model throws an exception if it finds a concurrency conflict that it can't solve on it's own. Essentially, the model tracks a revision number and date/user of creation and update. If the object being saved is out of date (older revision than in the data store), it attempts a merge. If it fails, the controller handles the exception and initiates some kind of resolution workflow.

The issue is with the client application; since ajax runs requests asynchronously, the model doesn't necessarily have the latest version of the data, but only the controller would know that--it is responsible for handling the queue/polling. The original idea was to pass all the updates fetched from the server directly to the javascript models for handling the concurrency--problem being that the lack of exceptions in javascript limits us to making flow-control decisions in the model that way.

Is it a bad idea to move the merging/model-conflict-resolution into the javascript controller? Is there a better way to handle this without the controller getting to far into model land?

Flow of the page:

  1. User loads page(ajax application) with initial models--the models are numerous and have many attributes.
  2. Page polls server for updates every 10-15 seconds--this is for auto-save and getting updates from other users.
  3. User edits models.
  4. Any conflicts that arise after initial entry are resolved when the user clicks the "save" button at the bottom of the page.
  • "The idea was to pass all the updates directly to the models for handling the concurrency, except that the lack of exceptions in javascript limits us to making flow-control decisions in the model that way." - this is not clear to me.
    – psr
    Commented Aug 30, 2011 at 0:40
  • @psr: is that a little more clear? It's a bit complicated, so I'm omitting a lot of details
    – Bryan Agee
    Commented Aug 30, 2011 at 1:43
  • It's not clear on what kind of MVC you are using for client side. Is it JavascriptMVC? Commented Aug 30, 2011 at 1:58
  • I wasn't using a client-side framework, just coding in the MVC paradigm (at least attempting to)
    – Bryan Agee
    Commented Aug 30, 2011 at 2:16
  • Still not sure what that sentence means. Why exactly is the lack of exceptions preventing you from doing (not fully sure what you are doing in regard to that sentence specifically). And why won't error callback functions work for you? I really think the answer is likely to depend on understanding these things.
    – psr
    Commented Aug 30, 2011 at 3:15

1 Answer 1


Not entirely clear on what you are doing. But here is what I am assuming, you are writing some kind of application with large number of users updating same values(like price of a stock) and you want to use MVC on the client stack(JS) to create an desktop application like feel.

Having concurrency control in the controller seems right. If it was me I would write the controller as a bunch of classes(functions) with extensive support for call back. If there was successful, call this, if it failed call this.

Then in the View, Ill call the controller functions with right call back functions.

Even though this will work, I feel the architecture is too complicated. Either keep the server as a model only communication(acquire lock on edit, update on save, release lock on success) or move everything to server and use JQuery ajax to just do all the work.

  • This matches my experience. The controller works best as the place to handle concurrency, and the architecture does sound overly complicated. Replicating the model on both the client and the server side, and trying to keep them in synch, sounds like over-kill. Commented Aug 30, 2011 at 6:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.