Im using SpringBatch 2.1.7 release core and Infrastructure jars to read a CSV file and save it to DB.
Integrated my code with Spring quartz scheduler to run for every minute, The Batch is working fine with reading and writing but its failing with the error "org.springframework.dao.OptimisticLockingFailureException: Attempt to update step execution id=1 with wrong version (2), where current version is 1"
due to Tx conflicts. Please suggest how can i resolve this issue.
I had this same exception.
org.springframework.dao.OptimisticLockingFailureException:
Attempt to update step execution id=0 with wrong version (2), where current version is 3
In my case, it was caused by a failure the process step, which was being swallowed. Spring Batch activated the writer, even though the processor had failed. Look through your logs to make sure that your process step is completing and returning something.
As pointed out by MattC, I had this error when my ItemProcessor was bugged. For some reason, during my processor activities, it was closing the datasource connection with jobrepository, so my exception was:
Encountered an error saving batch meta data for step step1 in job myjob. This job is now in an unknown state and should not be restarted.
org.springframework.dao.OptimisticLockingFailureException: Attempt to update step execution id=1 with wrong version (1), where current version is 2
At the end of the stacktrace, I was able to find:
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Connection is closed.
In order to identify the problem, first I isolate the phase. I constructed a NoOpProcessor and a NoOpItemWriter. Adjusted the tasklet and it worked well. So my problem wasn't into the reader.
Then I rolledback to my "full" ItemWriter implementation, and again, it worked well. So my problem wasn't with the writer to. When I enabled my "full" processor, the error occurred again. So, the error was in it, and I started debugging.
So, unfortunately, my answer is: debug...
public class NoOpProcessor implements ItemProcessor<Object, Object> {
@Override
public Object process(Object arg0) throws Exception {
System.out.println("Input object: " + Objects.toString(arg0));
return arg0;
}
}
public class NoOpItemWriter implements ItemWriter<Object> {
@Override
public void write(List<? extends Object> items) throws Exception {
if (items != null) {
System.out.println("Qtty of items to be written: " + items.size());
for (Object obj : items) {
System.out.println(Objects.toString(obj));
}
} else {
System.out.println("The items list is null. Nothing to be written.");
}
}
}
This can also happen when using Hibernate and updating to a version > 5. The problem is, that the sequence generation default changed. But if you still work with legacy sequences it gets all jumbled up. Indication for this issue are errors and warn logs before the actual exception occurs. They are something like this: SQL Error: 1, SQLState: 23000 and ORA-00001: Unique Constraint (..) violation.
We had negative primary key's in the table (set commit for each item).
To solve the issue, set the property hibernate.id.new_generator_mappings to falsein your persistence.xml.
Links:
While searching for a solution I stumbled on another issue that might cause this: Duplicate entries to persist while using MapJobRepositoryFactoryBean with ResourcelessTransactionManager (which is not suppose to persist the data.).
Link: http://ashamathavan.blogspot.com/2010/12/optimisticlockingfailureexception.html
