load test and OptimisticLockingFailureException comes up

[paulaqian]

I tried some load test(1000 records) using the split processing. The chunk size is set to 1. Multiple threads are used and OptimisticLockingFailureException is thrown. If I increased the chunk size then the issue is just gone. But what if I need the chunk size to be one and need it to be run in a multithread processing env?

Thanks,


The trace is as following:
org.springframework.dao.OptimisticLockingFailureEx ception: Attempt to update step execution id=2 with out of date version (1484)
at org.springframework.batch.execution.repository.dao .JdbcStepDao.update(JdbcStepDao.java:566)
at org.springframework.batch.execution.repository.Sim pleJobRepository.saveOrUpdate(SimpleJobRepository. java:262)
at org.springframework.batch.execution.step.simple.Si mpleStepExecutor$1.doInIteration(SimpleStepExecuto r.java:227)
at org.springframework.batch.repeat.support.TaskExecu torRepeatTemplate$ExecutingRunnable.run(TaskExecut orRepeatTemplate.java:224)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)

[lucasward]

I'm not sure I understand what you mean by 'split processing'. The optimistic locking bug was fixed in the current trunk.

[paulaqian]

You mean in the m5 nightly snapshot? Because I am using m4 now.

[lucasward]

Correct, M5-SNAPSHOT.

For some reason the version number was being decremented on rollback, which is what's causing the bug. It should only happen on rollback, and is likely simply masking the original error.