Announcement Announcement Module
No announcement yet.
Thread safety with multiple concurrent batch executions Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Thread safety with multiple concurrent batch executions


    I have a simple batch that read some records from the DB, apply some business logic and write the results in the DB.
    This batch is not an "heavy" batch, I read 4000 records and creates around 4000 too.
    This is kicked off from a user through a Web app and the batch runs synchronously (not ideal but ok for now).

    My potential problem (let me know if I am wrong) is that each batch component is a stateful singleton and can cause serious thread safety issues.

    Could I fix this make the beans "prototype"? I might have problems with the bean life cycle.

    Any other way?



  • #2
    The recommended approach for right now is to create each batch job in it's own ApplicationContext, that way there are no threading issues. You should be able to launch the job asynchronously though:


    • #3
      How can I have an app context for each batch in a web app?


      • #4
        Just because you're in a webapp, it doesn't mean you can't create an ApplicationContext. Something like:

        ApplicationContext context = new ClasspathXmlApplicationContext("myJob.xml");
        JobLauncher launcher = context.getBean("jobLauncher");
        Job job = context.getBean("myJob");
        JobExecution execution =, new JobParameters());
        If your JobLauncher is configured to be asynchronous, it will return a JobExecution without waiting for the job to complete. (Please note that I typed up the code above without trying it in a compiler, but it should be close)


        • #5
          N.B. the best way to ensure that you follow the best practice advice is to use a JobFactory that contains the code that Lucas posted. There is an example in the samples, and two usage examples (from JMX and Quartz, but the same pattern will work from anywhere, including a web app).


          • #6
            Assuming I get a new application context for the batch related objects. those objects relies on DAO wired with spring (separate xml config file).
            I don't want new instances of those DAOs.
            So will the new application context load only the batch objects and reused the existing DAO?


            • #7
              It does make sense to share the daos (from Spring Batch as well as your business ones). That is the way those samples work that I already mentioned.