This commit adds SAP HANA as a supported Spring Batch database, enabling
developers to seamlessly move their existing Spring Batch projects to SAP HANA
or easily starting new Spring Batch projects on SAP HANA.
This commit contains the following changes:
- Add SAP HANA to the DatabaseType enum
- Add HanaPagingQueryProvider and tests
- Add properties files for SAP HANA
Issue #2515
Due to the decoupling of `PagingAndSortingRepository` from
`CrudRepository` in Spring Data 3 [1], this test has to be updated
to use different repositories between the reader and the writer
according to the expected types for the `repository` property.
[1]: https://github.com/spring-projects/spring-data-commons/issues/2537
This commit removes the unconditional exposure of the transaction
manager as a bean in the application context. The transaction manager
is still taken from the BatchConfigurer and set where needed (ie on
JobRepository and StepBuilderFactory) as previously done,
but is not exposed anymore as a bean to prevent any clash with a user
defined transaction manager.
If no transaction manager is provided, a DataSourceTransactionManager
will be configured by default as required by batch (without being exposed
as a bean).
Resolves#816
* Upgrade to Jakarta EE 9
* Upgrade to Spring Framework 6
* Upgrade to Spring Integration 6
* Upgrade to Spring Data 3
* Upgrade to Spring AMQP 3
* Upgrade to Spring for Apache Kafka 3
LDIF support is still in progress waiting for the next
major version of Spring LDAP.
Closes#4027Closes#3656
This commit removes the deprecated Map-based job repository
and job explorer implementations with their respective DAOs.
Using the `EnableBatchProcessing` annotation now requires a
datasource bean to be defined in the application context.
This will be reviewed as part of #3942.
This commit is a first pass that updates related tests to use
the JDBC-based job repository/explorer with an embedded database.
A second pass should be done to improve tests by caching/reusing
embedded databases if possible.
Issue #3836
Replaces the deprecated
- type InstantiationAwareBeanPostProcessorAdapter
- type GenericTypeResolver
- method StringUtils::isEmpty
- field BigDecimal::ROUND_HALF_UP
Issue #3838
The constructors of the wrapper classes for primitives (Double,
Integer, Long) have been deprecated since JDK 9 and should no longer be
called. Instead the static factory #valueOf should be used.
Guarded the logging statements which do concatenation of strings
or calling toString on objects. When a log level isn't enabled
this still would produce garbage that would need to be collected.
Guarded all logging up to info, warn and error can be assumed to be
enabled on a production system.
Before this commit, metrics were not collected in a fault-tolerant step.
This commit updates the FaultTolerantChunkProcessor to collect metrics.
For the record, chunk scanning is not covered for two reasons:
1. When scanning a chunk, there is a single item in each write operation,
so it would be incorrect to report a metric called "chunk.write" for a
single item. We could argue that it is a singleton chunk, but still..
If we want to time scanned (aka individual) items, we need a more fine
grained timer called "scanned.item.write" for example.
2. The end result can be confusing and might distort the overall metrics
view in case of errors (because of the noisy metrics of additional transactions
for individual items).
As a reminder, the goal of the "chunk.write" metric is to give an overview
of the write operation time of the whole chunk and not to time each item
individually (this could be done using an `ItemWriteListener` if needed).
Resolves#3664
Before this commit, the expected behaviour when a skippbale exception
occurs in a fault tolerant chunk-oriented step was not documented in
details.
This commit update the docs and adds a sample for each case (when a
skippable exception occurs during read, process and write).
Resolves BATCH-2541
