This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Client will have to wait for the asynchronous process to complete. When the async process will be complete then only the response will be committed.
Actually this concept of asynchronous processing is not with respect to client. For the client it will take the same time to complete the request.
Think it in terms of server performance. Server has a limited number of threads in thread pool which can serve a client's request. If a request is taking a long time to complete then for that duration the thread will be blocked. This reduces the efficiency of server. Imagine a scenario where all the threads in the thread-pool are blocked. Now if a new request comes then it will have to wait for the existing threads to complete processing. This is not acceptable.
But in asynchronous processing of the request the thread which is serving the client request can return to the container without committing the response. So this thread doesn't have to wait for the lengthy operation to complete. It will put the request in async mode and then start the lengthy operation in a background thread, and return to container, without waiting for that operation to complete. This thread will now become available to serve other client requests.
Remember in async mode returning to the container does not commit the response. In fact its in the hands of background thread to commit the response by calling asyncContext.complete() or any of the dispatch() methods.
So async processing does not reduce the request processing time, but it increases the average number of threads available to handle any request.