Spring Batch contains a collection of tools and Java functions for working and processing large data volumes.
Spring Batch is extremely efficient in improving the performance of Java batch jobs, mainly through the usage of well-known optimization, classification, and partitioning techniques.
Some of the basic functions and operations that can be batched with the framework are:
- Job skipping
- Job restarts
- Job stops
- Job starts
- Job retries
- Basic resource management
- Data logging
- Data tracing
- Transaction management
- Statistics processing
The framework also scales very well, developers being able to use it on cloud computing environments, not just their regular stand-alone production or testing servers.
Spring Batch also comes with Spring Batch Admin, a visually pleasing and easy to use Web-based administration interface for managing and editing currently batched operations.
What is new in this release:
- CompositeItemProcessor.setDelegates argument has limiting generic type
- StaxEventItemWriter should only force sync once per chunk
- Relax OSGI dependencies on nosql jars
What is new in version 3.0.5:
- CompositeItemProcessor.setDelegates argument has limiting generic type
- StaxEventItemWriter should only force sync once per chunk
- Relax OSGI dependencies on nosql jars
What is new in version 3.0.4:
- CompositeItemProcessor.setDelegates argument has limiting generic type
- StaxEventItemWriter should only force sync once per chunk
- Relax OSGI dependencies on nosql jars
What is new in version 3.0.3:
- CompositeItemProcessor.setDelegates argument has limiting generic type
- StaxEventItemWriter should only force sync once per chunk
- Relax OSGI dependencies on nosql jars
What is new in version 2.1.9:
- Round trip Properties-String-Properties broken for short Strings in PropertiesConverter.
What is new in version 2.1.7:
- Bugs:
- CommandLineJobRunner fails if standard input not available
- MapJobInstanceDao.getJobInstances(String jobName, int start, int count) does not work
- BeanWrapperFieldSetMapper race condition in cache
- Inline step definitions clash if multiple instances share a TaskExecutorPartitionHandler
- Failure in RetryPolicy leads to infinite loop in Step
- Improvements:
- Add RemoteStepExecutionAggregator to update step executions from the repository during partition processing
- The step execution context is not deserialized by default and no API to do it effectively
- New Features:
- Late binding of commit-interval, retry-limit, skip-limit, e.g. bound from job parameters.
- DelimitedLineTokenizer always trims the input data
- Inefficient (and unnecessary?) locking in TaskletStep and CompositeItemStream
- Refactorings:
- Use Spring 3.0 OXM instead of SWS 1.5
Comments not found