Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MapStepExecutionDao throws an OptimisticLockingFailureException [BATCH-1778] #1812

Closed
spring-projects-issues opened this issue Aug 2, 2011 · 5 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 2, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 2, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 3, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 3, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 31, 2013

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

@benas
Copy link
Contributor

@benas benas commented Jan 21, 2021

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants