Tim Holloway wrote:Don't even think about it.
The servlet spec expressly forbids servlet code from spawning threads. Nor should you run synchronously, since you'll starve the HTTP request thread pool in addition to stalling browser response until the process is complete.
The asynchronous processing of requests serves several purposes. The underlying issue that is addressed is thread-starvation: asynchronous processing minimizes the number of threads necessary for performing the processing required for the Web Application. This is important in at least two major use cases:
the back end services accessed from the Servlet are slow (perhaps asynchronous themselves) – hanging on to the thread while the back end sits on its response maybe quickly become to costly. The support for asynchronous processing in Servlet 3.0 allows the Servlet to give up the thread and only to resume processing when the results are in
the client (browser) is not satisfied with just the initial response returned upon reception of the request; it is interested in additional results from the server, that should be sent (pushed) to the client as they originate on the server. This would yield an active web client that without end user intervention keeps getting refreshed (a bit like a Chat client, RSS reader or Email client that all get notified and show alerts when new messages arrive). This latter functionality is known as Server Push or Comet-style web applications. They can be achieved today, but most implementations use long running requests that keep server threads occupied and therefore do not scale well.