title: Spring Batch: problems (mix data) when converting to multithread
body: <p>Maybe this is a recurrent question, but I need some customization with my context.</p>
  
  <p>I'm using Spring Batch 3.0.1.RELEASE</p>
  
  <p>I have a simple job with some steps. One step is a chunk like this:</p>
  
  <pre><code>    &lt;tasklet transaction-manager="myTransactionManager"&gt;
  &lt;batch:chunk reader="myReader" processor="myProcessor" writer="myWriter" commit-interval="${commit.interval}"&gt;
  &lt;/batch:chunk&gt;
  </code></pre>
  
  <p></p>
  
  <pre><code>&lt;bean id="myProcessor" class="org.springframework.batch.item.support.CompositeItemProcessor" scope="step"&gt;
  &lt;property name="delegates"&gt;
      &lt;list&gt;
          &lt;bean class="...MyFirstProcessor"&gt;
          &lt;/bean&gt;
          &lt;bean class="...MySecondProcessor"&gt;
          &lt;/bean&gt;
      &lt;/list&gt;
  &lt;/property&gt;
  </code></pre>
  
  <p></p>
  
  <ul>
  <li><strong>Reader</strong>: JdbcCursorItemReader</li>
  <li><strong>Processor</strong>: CompositeProcessor with my delegates</li>
  <li><strong>Writer</strong>: CompositeWriter with my delegates</li>
  </ul>
  
  <p>With this configuration, my job works perfectly.</p>
  
  <p>Now, I want to convert this to a multi-threaded job.
  Following the <a href="http://docs.spring.io/spring-batch/reference/html/scalability.html#multithreadedStep" rel="noreferrer">documentation to basic multi-thread jobs</a>, I included a SympleAsyncTaskExecutor in the tasklet, but it failed.</p>
  
  <p>I have readed JdbcCursorItemReader does not work properly with multi-thread execution (is it right?). I have changed the reader to a JdbcPagingItemReader, and it has been a nightmare: job does not fail, writing process are ok, but data has mixed among the threads, and customer data were not right and coherent (customers <em>have got</em> services, addreses, etc. from <em>others</em>).</p>
  
  <p>So, why does it happen? How could I change to a multi-thread job?</p>
  
  <ul>
  <li>Are the composite processor and writer right for multithread? </li>
  <li>How could I make a custom thread-safe composite processor? </li>
  <li>Maybe could it be the JDBC reader: Is there any thread-safe JDBC reader for multi-thread?</li>
  </ul>
  
  <p>I'm very locked and confused with this, so any help would be very appreciated.
  Thanks a lot.</p>
  
  <p><strong>[EDIT - SOLVED]</strong></p>
  
  <p>Well, the right and suitable fix to my issue is to design the job for multithread and thread-safe execution from the beggining. It's habitual to practice first with one-thread step execution, to understand and know Spring Batch concepts; but if you consider you are leaving this phase behind, considerations like immutable objects, thread-safe list, maps, etc... must raise.</p>
  
  <p>And the current fix in the current state of my issue has been the next I describe later. After test Martin's suggestions and taking into account Michael's guidelines, I have finally fix my issue as good as I could. The next steps aren't good practice, but I couldn't rebuild my job from the beggining:</p>
  
  <ul>
  <li>Change itemReader to JdbcPagingItemReader with setState to false.</li>
  <li>Change List by CopyOnWriteArrayList.</li>
  <li>Change HashMap by ConcurrentHashMap.</li>
  <li>In each delegated processor, get a new instance of every bean property (fortunately, there was only one injected bean) by passing the context (implements ApplicationContextAware) and getting a unique instance of the bean (configure every injected bean as scope="prototype").</li>
  </ul>
  
  <p>So, if the delegated bean was:</p>
  
  <pre><code>&lt;bean class="...MyProcessor"&gt;
  &lt;property name="otherBean"  ref="otherBeanID" /&gt;
  </code></pre>
  
  <p></p>
  
  <p>Change to:</p>
  
  <pre><code>&lt;bean class="...MyProcessor"&gt;
  &lt;property name="otherBean"  value="otherBeanID" /&gt;
  </code></pre>
  
  <p></p>
  
  <p>And, inside MyProcessor, get a single instance for <em>otherBeanID</em> from the context; <em>otherBeanID</em> must be configurated with scope="protoype".</p>
  
  <p>As I tell before, they're no good style, but it was my best option, and I can assert each thread has its own and different item instance and other bean instance.</p>
  
  <p>It proves that some classes has not been well designed for a right multithread execution.</p>
  
  <p>Martin, Michael, thanks for your support.</p>
  
  <p>I hope it helps to anyone.</p>