Announcement Announcement Module
Collapse
No announcement yet.
Running Job concurrently Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Running Job concurrently

    In fact I have asked and found a solution in Spring Batch 1.x
    http://forum.springsource.org/showthread.php?t=52620

    As I am looking in upgrading to Spring Batch 2.x, I would want to see if there are other suggested way to do so.

    If my tasklet, reader, listener or any supporting beans contains stateful data during job execution, as all these jobs are singleton bean, if same job is executed multiple times concurrently, the internal state will be messed up.

    In the old time (Batch 1.x), I was told to put each job to run in a separate child app ctx, and it works fine (In fact I feel it is a GREAT way to do, for which every job is self contained). However related example are removed from Spring Batch 2.0. Does that mean there is better way to cater for such usage scenario?

  • #2
    scope="step"

    Comment


    • #3
      So the child app ctx way is no longer recommended?

      for step scope, what if I have a bean that is used by two steps (maybe as cache of some common data within the job etc), setting the bean as step scope will not work, right?

      Comment


      • #4
        Seems the "Run job in a separate child context" feature is added in 2.x already, am I right?

        classes like ClassPathXmlJobRegistry etc

        Comment


        • #5
          ClassPathXmlJobRegistry (now renamed ClassPathXmlJobLoader) is for loading the context, but you don't have to do that every time you run the job, so step scope is still the preferred state management option for separating step and job executions.

          Your bean that is used by two steps is presumably only used in a single job? Step scope is not the right tool in that case, but that's why we added an ExecutionContext to the JobExecution (in 1.1). A simple shared bean won't give you state persistence that is needed for restartability, but the execution context does.

          Comment


          • #6
            Originally posted by Dave Syer View Post
            ClassPathXmlJobRegistry (now renamed ClassPathXmlJobLoader) is for loading the context, but you don't have to do that every time you run the job, so step scope is still the preferred state management option for separating step and job executions.

            Your bean that is used by two steps is presumably only used in a single job? Step scope is not the right tool in that case, but that's why we added an ExecutionContext to the JobExecution (in 1.1). A simple shared bean won't give you state persistence that is needed for restartability, but the execution context does.
            Sometimes "no state persistence for restartability" is exactly what I want. I have some jobs that with 1 step prepare some data (e.g. a complicated lookup table) which will be used by several other forthcoming steps. I don't really need to persist those data (and I shouldn't because it doesn't make sense in such case, and it may be huge). Is there anyway to 'flag' certain values Job's execution context for not to be persisted?

            Comment


            • #7
              The step has allowStartIfComplete. In addition most of the out-of-the-box readers and writers if they are stateful have a saveState flag (which is just an optimization).

              Comment

              Working...
              X