Nov 30th, 2007, 02:16 AM
I want to integrate a batch console management that lists all available jobs and offers links to start/stop/schedule jobs. Regarding this, I have many questions (please correct me if any assumption is wrong) :
- What is the typical (recommended use) for the batch environment? One environment per batch (a job launcher, facade, etc with a configured jobConfigurationName and autostart=true) or a generic environement without configured jobName and invoked solely using the run(String name) or run(JobIdentifier id) (this second option will certainely require TaskExecutorJobLauncher, otherwise jobs can only be invoked serially).
- As I understand, the JobLauncher is the primary class for my purpose. Is there a single instance of this class or is there one instance per job execution ? i.e. is the job launcher a singleton or a protoype?
- In order to schedule jobs, shall I use the TaskExecutorJobLauncher and provide a TaskExecutor with scheduling capabilities, or shall I encapsulate the JobLauncher in a scheduler?
Maybe all above options are possible, but which one is recommended or, better stated, which one represents best your idea when you designed the framework?
In point 3 from above, if I use the TaskExecutor inside the JobLauncher, I might encounter problems when I schedule a job for a delayed execution, then invoke stop() : NoSuchJobConfigurationException because the job is not registered yet. Is this the way it should be, i.e. invoking start() does not ensure that I can invoke stop() right after ? In this case, I will certainely need to extend the JobLauncher for special delayed execution, by registering Futures in a map and cancelling one of them on stop() invocation, instead of directly stopping the container.
Thanks in advance for your responses.