Before this commit, the `RepositoryItemWriter` did not use
`CrudRepository#saveAll` by default and one must override
`doWrite` and call it manually, which is not convenient.
This commit makes the writer use `CrudRepository#saveAll`
by default while keeping the possibility to use another
method if desired through the `methodName` parameter.
Resolves#3720
I edited the leader paragraphs above each code block that
was flagged as being XML or Java content, such that the
paragraphs make sense when both the XML and the Java blocks
are present. I turned the Both button back on. I also caught
a bunch of other editing things.
Mahmoud Ben Hassine caught a couple of sentences that were
problematic when the Both option is on. I then caught a couple
of other problems. I fixed all of that.
Thanks for reading closely, Mahmoud. I always appreciate that.
TransactionAwareBufferedWriter offers a number of optimization
potentials. First it creates an unnecessary local, temporary char[]
in write(char[], int, int). Second it does not overwrite any of the
#write(String) methods leading to unnecessary intermediate copies.
* avoid local, temporary char[] in #write(char[], int, int)
* overwrite #write(String) methods to avoid copies
Together these two changes should help to reduce allocation rate.
Issue: #1166
I learnt that local storage is the preferred way to save a user's preferences. A cookie is sent to the server on every request, which makes for needless traffic. I "borrowed" the idea from the Spring Framework docs.
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
This commit fixes incorrect references to `AggregateItemReader#__$$BEGIN_RECORD$$__`
and `AggregateItemReader#__$$END_RECORD$$__` by updating the description of the
reader with the one in its Javadoc.
It also adds a note that the AggregateItemReader is not part of the standard library
of readers provided by Spring Batch but only given as a sample.
Issue #1793
