Understanding launching of Spring batch Jobs in a web container

I was reading the Spring Batch documentation when I came across the fact that we would have to use a different implementation of the TaskExecutor interface (The Asynchronous version) if we would efficiently have to run batch jobs from a web container.

I am assuming that an Http request would trigger the batch job. And as I understand it, when the client launches the job via the run method of the JobLauncher开发者_StackOverflow interface, the client has to wait for the JobExecution object to be returned back and since a typical batch job would run for hours at an end, this might not be very feasible if the jobs are executed synchronously. Now, the AsyncTaskExecutor would execute each step in separate threads and would return the JobExecution object immediately with an UNKNOWN status.

Firstly, can someone please explain to me, how this works from a client-server connection perspective? In each case, would the client not wait for the batch to be finished before he terminates the session? Or, would the client not know about the exit status of the batch job? Is the whole problem to do with the connection having to remain till the batch ends?

As an example, say the client has a web page which sends an HTTP get request, which is served by a servlet's doget method. This method calls the run method of the job launcher. This method will return the JobExecution object. And the rest of the story is as above.

Thanks, Aditya.

It depends a bit on what your servlet does after it has called the run method and received the JobExecution object in return. I will assume that the doget method just returns after run is called.

If you do not use an asynchronous executor the call to the run method on the job launcher will be executed synchronously. That is, the call will wait until the batch job is done and the JobExecution object is returned. From a connection perspective, the client's HTTP connection will remain open during the entire batch job. The HTTP connection will be closed when the servlet's doGet method returns (or before if some kind of timeout is encountered on some level, e.g. firewall or a socket read timeout).

If you do use a asynchronous executor the call to the run method will return immediately. The doGet method will return after that, the HTTP response will be sent to the client and the connection will be closed (assuming there is not HTTP keep-alive).

Running Jobs from within a Web Container

Usually jobs are launched from the command-line. However, there are many cases where launching from an HttpRequest is a better option. Many such use cases include reporting, ad-hoc job running, and web application support. Because a batch job by definition is long running, the most important concern is ensuring to launch the job asynchronously:

Here Spring MVC controller launches a Job using a JobLauncher that has been configured to launch asynchronously, which immediately returns a JobExecution. The Job will likely still be running, however, this nonblocking behaviour allows the controller to return immediately, which is required when handling an HttpRequest.

An example is below:

@Controller
public class JobLauncherController {

    @Autowired
    JobLauncher jobLauncher;

    @Autowired
    Job job;

    @RequestMapping("/jobLauncher.html")
    public void handle() throws Exception{
        jobLauncher.run(job, new JobParameters());
    }
}

source