In response to my Ajax/REST article
, Frank Staheli asked the following questions:
1. Can AJAX still take advantage of back-end database connection pooling (a huge disadvantage of client-server graphical apps, that they couldn't)? I would think so, but I'm not sure.
There is no conflict between the Ajax/REST architecture style I described in the article and database connection pooling. In fact if you're using J2EE, you can use pretty much any current J2EE facility you want, with the exception of JSP/JSF, which aren't necessary if you're doing pure Ajax/REST (although they are still relevant if your web app's a hybrid).
2. How does my AJAX app handle a server crash? Because would the readystate not change with no response from the server? Would the connection eventually time out?
First of all, I don't mess around with low-level XHR
stuff. I prefer to use higher-level frameworks like Dojo
which provide relatively abstract Ajax request invocation libraries - which do
time out after a period of time (and I believe this may even be user configurable in Dojo) and calls an error callback function which you control.
So how you deal with this error is purely a matter of user experience design. First remember that the only "critical time" where a server crash should affect a user is if the server is down when the user performs a gesture that causes a remote Ajax request to fire (or if a the Ajax app sends a background remote request - more on that later). With that in mind, also remember that a user using a web browser spends probably 95% of their time not interacting with the app but rather just looking at what's on their screen, so 95% of their time they're not invoking remote actions. It's entirely possible that the server could hiccup and come back between user interactions, and the user would be none-the-wiser (assuming a stateless server, which I strongly recommend).
If the user does cause a remote call to fire while the server is down, you simply have to follow normal user interface error handling guidelines. Provide an informative error message to the user and reassure them that your IT admins have been automatically alerted by your automated system management software (if you don't have this, IBM Tivoli
One other corner case - many Ajax apps perform background requests that aren't caused by user interactions (e.g. Gmail checking for new mail). If one of these background operations fail because the server isn't responding you can either choose to fail silently or warn the user that the server's down. You should fail silently if there's no chance that the user may lose work if the server's down. E.g. if your application's relatively read-only, you may as well wait to notify the user of a server problem until they perform an explicit action that requires server responsiveness since the server may come back before the user performs that action. If your application allows the user to create data (e.g. sending emails, filing bugs, etc.) you may want to proactively warn the user that there's a server problem and they won't be immediately able to save any data they enter until the server comes back online (this is another great use case for 'ping server to determine when it's back up' user experience described above). If you're REALLY on the cutting edge, you can use something like dojo.storage
that can store data locally for later remote replication, but this requires that the user have Flash installed, which has some consumability implications.
- Bill[Read More