Asynchronous Servlets vs. synchronous Servlets

Question

Since Servlet 3.0 asynchronous processing is supported. Would it be better, to use always asynchronous processing? Or in what cases is synchronous processing better?

Answer 1

Asynchronous processing have been introduced for the cases when there is no need to hold a thread during the whole request processing cycle. The typical example of such a case is a comet-like functionality.

Using asynchronous processing in all cases wouldn't worth anything, because usually back-end processing consumes a thread anyways.

Answer 2

Reading the article, asynchronous processing support in the Servlet 3.0 spec has a very specific use case - it is designed to handle the case where you have an AJAX application that makes requests that trigger potentially long-running processes in the background.

The reason we needed something like this was to respond to a problem in the thread-per-request model, which allocates a thread every time the client requests a page from the server, rather than allocating a single thread for the client's entire session. This worked well prior to AJAX when clients would make requests sporadically, but the benefits were lost when AJAX applications significantly increased the number of requests a client would make.

Specifically, if an AJAX request triggers something potentially slow or blocking, like a database operation, we are back where we started - threads from the server's threadpool are potentially idle.

Asynchronous processing support attempts to mitigate this by putting requests into a centralized queue, such that threads are not always stuck waiting for results of requests that might not have even started being processed yet. In short, we are trying to get the most bang for our buck out of our threads at all times - that is, decreasing the amount of time when they are idle (but could be serving some other connection).

Like any new developments, this is not something to be used as a one-size-fits-all tool. Look for the specific case in your application where it is appropriate.

Answer 3

I just skimmed over the linked article, this is a server-side improvement, not client-side asynchronous.

Summarising the article:

You would want to use Asynchronous servlets in a situation where you have a load of requests coming in (similar to bashing your server with AJAX requests), and you don't want to serve up one thread per request. TPR can be dangerous in this scenario when the processing time takes a little while, causing you to exhaust your thread pool.

The job will get stuck into a job queue and the thread can be retired until the job completes and the response is finally committed when the resources free up to allow it to complete.

Pretty cool stuff.

Answer 4

The big thing you get with asynchronous servlets is HTTP push, where the server can fire information back to the client when it chooses to, rather than when the client asks for it. Pre-asynch servlets, this would require long-running HTTP connections which each tied up a server thread, which is very inefficient. This new model decouples the server-side processing from the connection handling.