23 November 2006 - 17:03An interesting side-effect of AJAX

I was reading this interview on infoq with Gavin King when I came across this paragraph:
“Second (change in SEAM) is the new concurrency model. With the death of the old paradigm of coarse-grained synchronous request/response, the assumption that concurrent requests in the same session are very rare is totally turned on its head. It’s now absolutely essential to have strong constructs for managing session-level concurrency.”

It looks like one major change that AJAX brought to development is concurrent access to state that was previously regarded in general as non-concurrent . It is interesting to see how the access to data in a concurrent fashion will be implemented. SEAM suggests that you should do this on the server, as according to this quote: “If you want to build an Ajaxified JSF application using ICEfaces or Ajax4JSF, you will run into all kinds of performance and concurrency problems if you don’t use Seam.”
Another way to implement concurrent access to shared state would be in the client: all the AJAX calls will be routed thru a manager that would determine (based on some configuration, etc…) which calls are to be serialized and which are to be executed immediately. BUT, AJAX is an asynchronous protocol, so you cannot serialize these calls at the client level because you do not know the order in which they will be executed on the server… *
So, it looks like we will have to deal with shared state more and more. The fact that this shared state is usually distributed and replicated (for handling fail-over, for example) makes it even more interesting. It would be interesting to see how this unfolds…
Later edit: I think you could serialize method calls that use AJAX calls in the browser by running them in a browser-based container that waits for a response from ther server to an AJAX call before making the next call. I don’t think I expressed it correctly though and I don’t have time to dwell on it…