Search:

You need to give a unique job parameter. An easy way to do this is to use the RunIdIncrementer which just assigns an integer to each job instance and adds one for each new instance.

I would do the file rejection in a separate step. There's actually a sample called SkipSample that does something like this. After the processing step, it check to see if there are any skips. ...

No, when you insert the records, have a field that's like NEED_TO_DELETE_OTHER_THING=TRUE.

Then your delete statement can say:


delete from T
inner join INSERT_TABLE on...

The transaction wraps around the entire ItemWriter.write() call, so putting both calls in the same ItemWriter or using a CompositeItemWriter wouldn't help you. It seems like the easiest thing would...

In your other post you said that you want to fail the whole file if a records fails to validate, but here you are saying that you want to simply skip the record and keep going. I'm confused about...

This is almost always unnecessary. If you want a particular type of exception to fail the job, then the preferred way is to simply make that exception non-skippable. (That is, if your step allows...

The ItemProcess is the best place to do validation. This allows you to keep the validation separate from the reading and writing. It also lets you cleaning ignore bad records by simply returning...

Usually it's better to do these sorts of things in the xml. You could, for instance, create an abstract <job/> that only has the listener on it and then all of your concrete jobs could have a...

By default, the job status information is stored into the batch metadata tables in the database: http://static.springsource.org/spring-batch/reference/html/metaDataSchema.html

You need to do it like this:


Object item = it.next();
if(item instanceof A) {
A a = (A)item;
}
else if(item instanceof B) {
B b = (B)item;
}

To perform a single action (as opposed to an action for each item) use a custom Tasklet.

As for polling, maybe have an intermediate step that loops until the db is ready, sleeping for a bit on...

You can write a wrapper for the SingleItemPeekableItemReader (that in turn wraps a JdbcCursorItemReader). The wrapper will build a list containing all of the account records that make up one group. ...

This is rarely (if ever) a good approach. It loses the benefit of checkpointing your progress that Spring Batch provides and also opens you up for the possibility of running out of memory.

The...

Use PatternMatchingCompositeLineMapper to handle the different line types differently. When you handle the header, store its data into the Step ExecutionContext so that it can be used in the future...

Maybe put all of the information into a List and put that list (serialized) into the context? That way you don't need to know the individual names, you could just iterate through the list.

Just create a FieldExtractor wrapper that puts quotes around the fields. Then you can wire that into the DelimitedLineAggregator.

It would be easy to set up a job that was launched, for instance, every minute and checked for any new work to be performed.

You have a bean called 'dataSourceInitializer' that is trying to create the batch tables. However, the tables apparently already exist. So you should remove the initializer since it is not needed.

The reason we transform null to empty string is that in the majority of cases, null should be represented in the output as blanks, not "null". Your case is special because you are using a date-based...

You can just write a java program with a main() method modeled after or wrapping the CommandLineJobRunner.


Also, it's not very useful for you to ask again for help only one hour after the...

You might try parallelizing your job: http://static.springsource.org/spring-batch/reference/html/scalability.html

An automatically generated RowMapper will not help you in this case. You need to either write your own RowMapper that includes all of the columns, or use the BeanPropertyRowMapper.

You need to define a bean for a class that implements RowMapper. See http://static.springsource.org/spring-batch/reference/html/readersAndWriters.html#JdbcCursorItemReader.

The RowMapper doesn't have any concept of which tables the columns originated from: it sees multiple tables the same way it sees one table. You can use the information here:...

You use the <listener/> tag, as shown in the section on listeners (http://static.springsource.org/spring-batch/reference/html/configureStep.html#interceptingStepExecution) and the section on passing...