From 939d9a1914827b9e79ccec5cfd9a3a6edbc9ab3d Mon Sep 17 00:00:00 2001 From: dsyer Date: Sat, 4 Sep 2010 10:37:35 +0000 Subject: [PATCH] tidy up docs --- src/site/docbook/reference/scalability.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/site/docbook/reference/scalability.xml b/src/site/docbook/reference/scalability.xml index 9077c518c..a34516490 100644 --- a/src/site/docbook/reference/scalability.xml +++ b/src/site/docbook/reference/scalability.xml @@ -9,7 +9,7 @@ meets your needs before thinking about more complex implementations. Measure the performance of a realistic job and see if the simplest implementation meets your needs first: you can read and write a file of several hundred - megabytes in well under a minute, even with bog standard hardware. + megabytes in well under a minute, even with standard hardware. When you are ready to start implementing a job with some parallel processing, Spring Batch offers a range of options, which are described in @@ -239,9 +239,9 @@ </partition> </step> - Similar to the multi-threaded step, there is a setting here - for a throttle limit, which prevents the task executor from being - saturated with requests from a single step. + Similar to the multi-threaded step's throttle-limit + attribute, the grid-size attribute prevents the task executor from + being saturated with requests from a single step. There is a simple example which can be copied and extended in the unit test suite for Spring Batch Samples (see