As I mentioned earlier, my main concern is to avoid the OptimisticLockingException being thrown by Spring Batch saying that there was an incorrect version of step while updating it. As I understand from the posts having two transaction managers wouldn't sort this out, right ? So what else I can do to not to get this exception ? Couldn't this be a bug in Spring Batch ? I'm using version 2.1.7.Quote:
Originally Posted by cnmconsulting
I would recommend using 2.1.8 over 2.1.7, but that won't necessarily make locking errors go away. There could be a bug, I suppose, but we haven't got enough information to see what you do - this is the first I heard about your OptimisticLockingException. All I can say for sure is that using a second database and transaction manager is definitely not the way to fix it.
I actually tried 2.1.8 as well but it didn't help.
The OptimisticLockingException usually occurs when something fails during the step execution.
Here is a stacktrace:
Quote:
Caused by: Exception [EclipseLink-5006] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.OptimisticLockE xception
Exception Description: The object table.View@2302 cannot be updated because it has changed or been deleted since it was last read.
Class> table.View Primary Key> 754
at org.eclipse.persistence.exceptions.OptimisticLockE xception.objectChangedSinceLastReadWhenUpdating(Op timisticLockException.java:137)
at org.eclipse.persistence.descriptors.VersionLocking Policy.validateUpdate(VersionLockingPolicy.java:76 6)
at org.eclipse.persistence.internal.queries.DatabaseQ ueryMechanism.updateObjectForWriteWithChangeSet(Da tabaseQueryMechanism.java:1167)
at org.eclipse.persistence.queries.UpdateObjectQuery. executeCommitWithChangeSet(UpdateObjectQuery.java: 84)
at org.eclipse.persistence.internal.queries.DatabaseQ ueryMechanism.executeWriteWithChangeSet(DatabaseQu eryMechanism.java:291)
at org.eclipse.persistence.queries.WriteObjectQuery.e xecuteDatabaseQuery(WriteObjectQuery.java:58)
at org.eclipse.persistence.queries.DatabaseQuery.exec ute(DatabaseQuery.java:808)
at org.eclipse.persistence.queries.DatabaseQuery.exec uteInUnitOfWork(DatabaseQuery.java:711)
at org.eclipse.persistence.queries.ObjectLevelModifyQ uery.executeInUnitOfWorkObjectLevelModifyQuery(Obj ectLevelModifyQuery.java:108)
at org.eclipse.persistence.queries.ObjectLevelModifyQ uery.executeInUnitOfWork(ObjectLevelModifyQuery.ja va:85)
at org.eclipse.persistence.internal.sessions.UnitOfWo rkImpl.internalExecuteQuery(UnitOfWorkImpl.java:28 42)
at org.eclipse.persistence.internal.sessions.Abstract Session.executeQuery(AbstractSession.java:1521)
at org.eclipse.persistence.internal.sessions.Abstract Session.executeQuery(AbstractSession.java:1503)
at org.eclipse.persistence.internal.sessions.Abstract Session.executeQuery(AbstractSession.java:1463)
at org.eclipse.persistence.internal.sessions.CommitMa nager.commitChangedObjectsForClassWithChangeSet(Co mmitManager.java:265)
at org.eclipse.persistence.internal.sessions.CommitMa nager.commitAllObjectsWithChangeSet(CommitManager. java:128)
at org.eclipse.persistence.internal.sessions.Abstract Session.writeAllObjectsWithChangeSet(AbstractSessi on.java:3766)
at org.eclipse.persistence.internal.sessions.UnitOfWo rkImpl.commitToDatabase(UnitOfWorkImpl.java:1404)
at org.eclipse.persistence.internal.sessions.Repeatab leWriteUnitOfWork.commitToDatabase(RepeatableWrite UnitOfWork.java:616)
... 38 more
@collector <collectorScheduler-2> [] ERROR #AbstractStep # Encountered an error saving batch meta data. This job is now in an unknown state and should not be restarted.
org.springframework.dao.OptimisticLockingFailureEx ception: Attempt to update step execution id=4 with wrong version (1), where current version is 2
at org.springframework.batch.core.repository.dao.Jdbc StepExecutionDao.updateStepExecution(JdbcStepExecu tionDao.java:185)
at org.springframework.batch.core.repository.support. SimpleJobRepository.update(SimpleJobRepository.jav a:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoi npointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethod Invocation.invokeJoinpoint(ReflectiveMethodInvocat ion.java:183)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :150)
at org.springframework.transaction.interceptor.Transa ctionInterceptor.invoke(TransactionInterceptor.jav a:110)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :172)
at org.springframework.aop.framework.JdkDynamicAopPro xy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy36.update(Unknown Source)
at org.springframework.batch.core.step.AbstractStep.e xecute(AbstractStep.java:244)
at org.springframework.batch.core.job.SimpleStepHandl er.handleStep(SimpleStepHandler.java:135)
at org.springframework.batch.core.job.flow.JobFlowExe cutor.executeStep(JobFlowExecutor.java:61)
at org.springframework.batch.core.job.flow.support.st ate.StepState.handle(StepState.java:60)
at org.springframework.batch.core.job.flow.support.Si mpleFlow.resume(SimpleFlow.java:144)
at org.springframework.batch.core.job.flow.support.Si mpleFlow.start(SimpleFlow.java:124)
at org.springframework.batch.core.job.flow.FlowJob.do Execute(FlowJob.java:135)
at org.springframework.batch.core.job.AbstractJob.exe cute(AbstractJob.java:281)
at org.springframework.batch.core.launch.support.Simp leJobLauncher$1.run(SimpleJobLauncher.java:120)
at org.springframework.core.task.SyncTaskExecutor.exe cute(SyncTaskExecutor.java:48)
at org.springframework.batch.core.launch.support.Simp leJobLauncher.run(SimpleJobLauncher.java:114)
..............
at org.springframework.scheduling.support.DelegatingE rrorHandlingRunnable.run(DelegatingErrorHandlingRu nnable.java:51)
at java.util.concurrent.Executors$RunnableAdapter.cal l(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndRe set(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(Future Task.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.access$101(ScheduledThreadPoolE xecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.runPeriodic(ScheduledThreadPool Executor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$S cheduledFutureTask.run(ScheduledThreadPoolExecutor .java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
I can't tell for sure, but it looks like the error in the Batch meta data was triggered by a business exception in eclipselink (optimistic lock failing for table.View). If you use JPA in your Batch components be sure to flush the changes manually in an ItemWriter (or similar), so that those errors don't show up during the transaction commit, which Batch relies on heavily to succeed as sign that all is well.
In my ItemWriter I'm delegating all calls to DAO components, so I'm not sure where I shall call the flush method.
Here is a pseudo code of my writer
The OptimisticLockException usually happens inside of anotherDao.doSomethingWithItems(items).Quote:
public MyWriter implements ItemWriter<Item> {
MyDAO myDAO;
AnotherDao anotherDAO;
write(List<? extends Item> items) {
for(Item item : items) {
myDAO.persist(item)
}
anotherDao.doSomethingWithItems(items);
}
So where flush should be called ?
Are you sure about that? The stack trace you posted shows the exception being thrown in commit (not in anotherDao). It is a sign that you are working concurrently with the same items in another process or thread. Does that sound plausible? Or maybe the implementation of anotherDao needs some investigation. Can you run the ItemWriter on its own in an integration test, simulating the conditions in the Batch job, but without any Batch?
JPA writers should flush at the end of write() or via an ItemWriteListener.
The first OptimisticLockingException (org.eclipse.persistence.exceptions.OptimisticLock E xception
Exception Description: The object table.View@2302 cannot be updated because it has changed or been deleted since it was last read. ) happening in my app is actually expected, as the table.View is being concurrently updated from several threads.
I would think though that it shouldn't cause the OptimisticLockingException in Spring Batch (#AbstractStep # Encountered an error saving batch meta data. This job is now in an unknown state and should not be restarted.
org.springframework.dao.OptimisticLockingFailureEx ception: Attempt to update step execution id=4 with wrong version (1), where current version is 2)