MapStepExecutionDao throws an OptimisticLockingFailureException [BATCH-1778]

[spring-projects-issues]

Yann Moisan opened BATCH-1778 and commented

Hi,

I use a multi-threaded step (via a ThreadPoolTaskExecutor) and I encountered an unexpected OptimisticLockingFailureException.

According to the javadoc of class MapJobRepositoryFactoryBean, it should work (Not suited for use in multi-threaded jobs with splits, although it should be safe to use in a multi-threaded step).

Here is the configuration of the job repository :

<bean id="jobRepository"
     class="org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean">
     <property name="transactionManager">
          <bean
               class="org.springframework.batch.support.transaction.ResourcelessTransactionManager" />
     </property>
</bean>

FYI, I've already encountered a strange behaviour, cf https://jira.springsource.org/browse/BATCH-1774.

Here is the stack trace:
org.springframework.dao.OptimisticLockingFailureException: Attempt to update step execution id=2 with wrong version (1), where current version is 2
	at org.springframework.batch.core.repository.dao.MapStepExecutionDao.updateStepExecution(MapStepExecutionDao.java:98)
	at org.springframework.batch.core.repository.support.SimpleJobRepository.update(SimpleJobRepository.java:171)
	at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy1.update(Unknown Source)
	at org.springframework.batch.core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:432)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
	at org.springframework.batch.core.step.tasklet.TaskletStep$2.doInChunkContext(TaskletStep.java:264)
	at org.springframework.batch.core.scope.context.StepContextRepeatCallback.doInIteration(StepContextRepeatCallback.java:76)
	at org.springframework.batch.repeat.support.TaskExecutorRepeatTemplate$ExecutingRunnable.run(TaskExecutorRepeatTemplate.java:257)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
	at java.lang.Thread.run(Thread.java:736)

---

Affects: 2.1.7

1 votes, 1 watchers

[spring-projects-issues]

Dave Syer commented

Are you saying this is related to BATCH-1774? Are there any other exceptions logged? Any reason you can't use an in-memory RDBMS?

[spring-projects-issues]

Yann Moisan commented

Are you saying this is related to BATCH-1774?
It's not really related ... I just mean that the problem might come from the same cause : thread visibility memory management. Indeed, the same code works perfectly when it is running on Windows with Sun JDK.

Are there any other exceptions logged?
No.

Any reason you can't use an in-memory RDBMS?
YAGNI.

[spring-projects-issues]

Dave Syer commented

It is interesting that you only see this on the multi-core and the IBM JRE. What about the Sun JRE on AIX?

YAGNI

Maybe you do need it then :) H2 is very lightweight and has far more love and a more careful implementation than a thing I threw together essentially for testing purposes.

[spring-projects-issues]

Philippe Mouawad commented

Hello,
First thanks for your great frameworks and work.

I faced the same issue with exact same Exception today on Linux RH 5 and Sun/Oracle JDK 1.6u16 64 bit with following configuration:
<bean id="jobRepository"
class="org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean"
p:transactionManager-ref="txManager" lazy-init="true"
autowire-candidate="false">
<property name="isolationLevelForCreate" value="ISOLATION_DEFAULT" />
</bean>

Switching to org.springframework.batch.core.repository.support.JobRepositoryFactoryBean fixed issue.

Documentation http://static.springsource.org/spring-batch/apidocs/org/springframework/batch/core/repository/support/MapJobRepositoryFactoryBean.html says:
"Not suited for use in multi-threaded jobs with splits, although it should be safe to use in a multi-threaded step."

I was in multi-threaded step without splits and I faced the issue.
I think this issue is not a minor one and should be fixed, at least documentation should mention not to use it in multi-threaded step if it doesn't work.

Regards

[fmbenhassine]

The MapJobRepositoryFactoryBean and all Map-based DAOs behind it were deprecated in #3780 and will be removed in v5 (#3836), so I see no value in putting efforts on those classes for the rest of their short lifetime. Those classes are not intended for production use anyway (as mentioned in the Javadoc and in this previous comment).