diff --git a/pom.xml b/pom.xml index aa16febf3..d8d7a4327 100644 --- a/pom.xml +++ b/pom.xml @@ -620,6 +620,11 @@ Dan Garrette dhgarrette@gmail.com + + mminella + Michael Minella + mminella@vmware.com + @@ -643,21 +648,5 @@ false - - com.springsource.repository.bundles.release - SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases - http://repository.springsource.com/maven/bundles/release/ - - false - - - - com.springsource.repository.bundles.release - SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases - http://repository.springsource.com/maven/bundles/release/ - - false - - diff --git a/spring-batch-core/src/site/apt/outline.apt b/spring-batch-core/src/site/apt/outline.apt index 4a95c4a28..d500ed334 100644 --- a/spring-batch-core/src/site/apt/outline.apt +++ b/spring-batch-core/src/site/apt/outline.apt @@ -1,20 +1,20 @@ ------------------------------------------ The Spring Batch - Reference Documentation ---------------------------------------- - Wayne Lund, Waseem Malik, Lucas Ward, Scott Wintermute, + Wayne Lund, Waseem Malik, Lucas Ward, Scott Wintermute, Kerry O'Brien, Tomi Vanek ------------------------------------------- May 2007 Preface -*1. {{{introduction.html}Spring Container Batch Processing}} +*1. {{{./introduction.html}Spring Container Batch Processing}} *1.1. Overview *1.2 Usage Scenarios -*2. {{{overview.html}Architecture Overview}} +*2. {{{./overview.html}Architecture Overview}} **2.1. Introduction to Architecture Layers @@ -25,11 +25,11 @@ Preface **2.4 Container Support Layer **2.5 The Container Core Layer - + **2.6 Using the Spring-batch infrastructure - + *2.6.1 Infrastructure Provided I/O Support - + *2.6.2 Infrastucture Provided Base Services *2.7. Batch Execution Container Configurations @@ -40,7 +40,7 @@ Preface *2.7.3 Batch Execution Container Hosted in J2EE Container - managed environment - + *3. Core Batch Services *3.1. Launching Batch Jobs @@ -119,6 +119,6 @@ Preface *7. [INCUB:Batch XML Schema] -*8. {{{glossary.html}Glossary}} +*8. {{{./glossary.html}Glossary}} diff --git a/src/site/apt/building.apt b/src/site/apt/building.apt index 8eb8d8b33..8d14e5cc9 100644 --- a/src/site/apt/building.apt +++ b/src/site/apt/building.apt @@ -17,8 +17,8 @@ $ mvn install or the goal of your choice (compile, test, etc.). This builds the artifact (e.g. jar file) from the project in the current directory, and deploys it to you local m2 repo at - <<<${user.home}/.m2/repository>>>. If there are any dependency resolution - problems try + <<<${user.home}/.m2/repository>>>. If there are any dependency resolution + problems try +--- $ mvn install -P bootstrap @@ -48,7 +48,7 @@ $ mvn -N install * Skipping Tests - The profile <> skips all the tests, so + The profile <> skips all the tests, so +--- mvn -o install -P fast @@ -59,7 +59,7 @@ mvn -o install -P fast * Running Individual Tests - The standard way to do this with Maven is -Dtest= with the class name (not fully qualified), e.g. + The standard way to do this with Maven is -Dtest= with the class name (not fully qualified), e.g. +--- $ mvn test -Dtest=FootballJobFunctionalTests @@ -121,12 +121,12 @@ $ mvn -P snapshots dependency:tree +--- in your <<<~/.subversion>>> (or <<\Application Data\Subversion/config>>>). If anyone forgets to do that then the property can be recursively set using Tortoise (type in the property key and value and use the recursive checkbox). - + * Documentation With the exception of reference docs, please put content in the project that it is most closely associated with. Here is a - {{{sitemap.html}site map}} to help you decide. + {{{./sitemap.html}site map}} to help you decide. ** Quotidian Web Content @@ -270,7 +270,7 @@ in a browser (it's the ALT content)... +--- mvn site:run +--- - + and go to http://localhost:8080. In a project with unit tests, you can skip the tests and go straight @@ -282,7 +282,7 @@ mvn -o site:run -P fast If you are offline, or want to speed things up a bit, the "-o" stops Maven from trying to resolve dependencies on the internet. - + Use -N to build only the current project, not subprojects, So this is pretty useful at the top level: @@ -295,7 +295,7 @@ mvn -N -o site:run -P fast xml file with a chapter in it. There is no link to these pages on the site because the real docbook generated output is much nicer, but this is still pretty useful for debugging and dynamic - editing. + editing. Note that the formatting is a bit limited compared to the whole docbook stylesheet - Maven uses Doxia to squish all of docbook into @@ -310,7 +310,7 @@ mvn -N -o site:run -P fast * Building and deploying the web site There is a bug in the m2 reactor (MNG-740) which means that we have - to install the parent pom to the local repo first. + to install the parent pom to the local repo first. So do it this way: @@ -339,7 +339,7 @@ Problems? your local Spring Batch repo <<<${user.home}/.m2/repository/org/springframework/batch>>>. If necessary, delete a project or directory and update from SVN again. - + Try +--- diff --git a/src/site/apt/cases/async.apt b/src/site/apt/cases/async.apt index a954bbcbe..2255d5ba3 100644 --- a/src/site/apt/cases/async.apt +++ b/src/site/apt/cases/async.apt @@ -43,7 +43,7 @@ Use Case: Asynchronous Chunk Processing * Description - The vanilla case proceeds as for normal {{{chunks.html}chunk + The vanilla case proceeds as for normal {{{./chunks.html}chunk processing}}, but: [[1]] Within a chunk, Container processes records in parallel. diff --git a/src/site/apt/cases/chunks.apt b/src/site/apt/cases/chunks.apt index bf13d81a1..0f3e129d7 100644 --- a/src/site/apt/cases/chunks.apt +++ b/src/site/apt/cases/chunks.apt @@ -63,7 +63,7 @@ Use Case: Commit Batch Process Periodically creates <<>> for it. [[1]] Client reads a line from the file, and converts it to a - database statement, then runs it. + database statement, then runs it. [[1]] Container increments counter. @@ -93,7 +93,7 @@ Use Case: Commit Batch Process Periodically If there is an error in the input data in the middle of a chunk (could be manifested as database exception, e.g. uniqueness exception, or nullable exception): - + [[1]] Container rolls back current transaction. [[1]] Container terminates batch and notifies client of precise @@ -117,7 +117,7 @@ Use Case: Commit Batch Process Periodically * Implementation * The concept of a batch iterator seems relevant here (see also the - {{{simple.html}simple}} use case). The iterator could be more than + {{{./simple.html}simple}} use case). The iterator could be more than just a loop that might terminate early: here it could also manage the file cursor on the input source. In this design there is a <<>> interface that can take care of termination and @@ -161,7 +161,7 @@ Use Case: Commit Batch Process Periodically is to retain this separation in a batch operation. The batch framework itself might provide some of these synchronizations. - * The {{{simple.html}Simple Batch Repeat}} is actually a pretty good + * The {{{./simple.html}Simple Batch Repeat}} is actually a pretty good model for the chunk processing in this use case. This observation leads to another: that a batch of chunks is a nested (or composed) batch - the outer termination policy is dependent only on the data diff --git a/src/site/apt/cases/file-to-file.apt b/src/site/apt/cases/file-to-file.apt index 9ba24799f..53a6bc45d 100644 --- a/src/site/apt/cases/file-to-file.apt +++ b/src/site/apt/cases/file-to-file.apt @@ -41,7 +41,7 @@ Use Case: Copy File to File * Description - Very similar to the use case {{{chunks.html}Copy File to + Very similar to the use case {{{./chunks.html}Copy File to Database}}, but involving transactional access to an output source which is a file. Also we are introducing the idea of an aggregate function for the output. @@ -60,7 +60,7 @@ Use Case: Copy File to File * Variations * Chunk failure variations proceed as in the use case - {{{chunks.html}Copy File to Database}}. In the case of a + {{{./chunks.html}Copy File to Database}}. In the case of a restart after fatal failure, the intermediate output file need does not need to be reset or re-created. diff --git a/src/site/apt/cases/index.apt b/src/site/apt/cases/index.apt index 9a0bfdb02..c544aa4cb 100644 --- a/src/site/apt/cases/index.apt +++ b/src/site/apt/cases/index.apt @@ -14,29 +14,29 @@ Use Cases for Spring Batch in this project, and use cases are a useful resource to make sure they are all agreed on scope and certain implementation details. - * {{{simple.html}Simple Batch Repeat}} + * {{{./simple.html}Simple Batch Repeat}} - * {{{retry.html}Automatic Retry After Failure}} + * {{{./retry.html}Automatic Retry After Failure}} - * {{{chunks.html}Commit Batch Process Periodically}}: chunk + * {{{./chunks.html}Commit Batch Process Periodically}}: chunk processing. - * {{{async.html}Asynchronous Chunk Processing}}: parallel + * {{{./async.html}Asynchronous Chunk Processing}}: parallel processing within a chunk. - - * {{{file-to-file.html}Copy File to File in a Batch}} - * {{{parallel.html}Massively Parallel Batch Processing}}. Spring + * {{{./file-to-file.html}Copy File to File in a Batch}} + + * {{{./parallel.html}Massively Parallel Batch Processing}}. Spring Batch 1.0 does not contain any implementations of this use case, but it is quite feasible to implement them using the framework as a starting point. 1.1 has some prototype code under the Integration module. - * {{{restart.html}Manual Restart After Failure}} + * {{{./restart.html}Manual Restart After Failure}} - * {{{steps.html}Sequential Processing of Dependent Steps}} + * {{{./steps.html}Sequential Processing of Dependent Steps}} - * {{{partial.html}Partial Processing}}: skip records (e.g. on rollback). + * {{{./partial.html}Partial Processing}}: skip records (e.g. on rollback). * Whole-Batch Transaction - transactional support for the whole batch, not just chunks. Quite a common requirement, but not @@ -45,16 +45,16 @@ Use Cases for Spring Batch copy it in one big batch (e.g. using native database tools) or chunk it (e.g. if it is now in a form for which chunk failure is easier to deal with). - - * {{{scheduled.html}Scheduled Processing}}: Batch Jobs controlled + + * {{{./scheduled.html}Scheduled Processing}}: Batch Jobs controlled by scheduler (e.g. start, stop, suspend, kill). Spring Batch does not intend to implement the scheduler concerns, but needs to provide enough information that a scheduler can act appropriately. - + * Non-Sequential Processing of Steps (Conditional Branching) - * {{{pause.html}Pause and Resume Job Execution}} + * {{{./pause.html}Pause and Resume Job Execution}} * Actors diff --git a/src/site/apt/cases/partial.apt b/src/site/apt/cases/partial.apt index fc5dd63fe..015ff5a19 100644 --- a/src/site/apt/cases/partial.apt +++ b/src/site/apt/cases/partial.apt @@ -44,7 +44,7 @@ Partial Processing The vanilla flow proceeds as follows: [[1]] Batch processing begins as per normal (see for example - {{{chunks.apt}chunk processing use case}}). + {{{./chunks.apt}chunk processing use case}}). [[1]] A record is processed. This step repeats until... @@ -68,7 +68,7 @@ Partial Processing ** Abort Batch Early The batch cannot skip all records. After each failure the decision - about whether to coninue has to be made: + about whether to coninue has to be made: [[1]] When a record is processed successfully, Container logs the event in a form that can be used later to identify successful @@ -94,8 +94,8 @@ Partial Processing * The decision to abort is based on exception classification. Each time an item is processed, the framework needs to catch exceptions - and classify them as - + and classify them as + * fatal: signals an abort - rethrow. * transient: nominally fatal, but the operation is retryable. @@ -103,7 +103,7 @@ Partial Processing * non-fatal: signals a skip. The transient failure is really just a sub-type of fatal case. It - is treated differently by the {{{retry.html}retry framework}} but + is treated differently by the {{{./retry.html}retry framework}} but not necessarily by the vanilla batch. * Actually we can't decide what action to take simply on the @@ -136,7 +136,7 @@ public void iterate(RepeatCallback callback) { the whole <<>> was transactional we need to rethrow * If the processing is asynchronous, the template has to execute in - a separate thread (see {{{async.html}asynchronous example}}). In + a separate thread (see {{{./async.html}asynchronous example}}). In this case the whole thread (i.e. the <<>>) has to be transactional. Whoever is counting failed items needs to be poooling information from multiple threads. diff --git a/src/site/apt/cases/restart.apt b/src/site/apt/cases/restart.apt index 4bbd564a6..8f703d5ef 100644 --- a/src/site/apt/cases/restart.apt +++ b/src/site/apt/cases/restart.apt @@ -14,7 +14,7 @@ Use Case: Manual Restart After Failure resources. A key goal is that the management of the batch process (locating a job and its input and results, starting, scheduling, restarting) should be as easy as possible for a non-developer, like - an application support team with some business back up. + an application support team with some business back up. * Scope @@ -59,7 +59,7 @@ Use Case: Manual Restart After Failure * Variations * Some restarts might lend themsleves to being handled automatically - - see the use case {{{retry.html}Automatic Retry}}. + - see the use case {{{./retry.html}Automatic Retry}}. * Implementation diff --git a/src/site/apt/cases/retry.apt b/src/site/apt/cases/retry.apt index da5b87c21..5ea21cac7 100644 --- a/src/site/apt/cases/retry.apt +++ b/src/site/apt/cases/retry.apt @@ -102,7 +102,7 @@ Use Case: Automatic Retry should not be retried (they will always fail the same way). ** Early Termination - + Normally client code is unaware of the Framework, but occasionally emergency measures might be taken inside client code where all further retry attempts are vetoed for the current block. @@ -122,7 +122,7 @@ Use Case: Automatic Retry * A back-off delay is used at the of the retry before any other transactional resources are enlisted. -* Implementation +* {Implementation} * The vanilla case and most of the variations can be achieved with a simple template approach: @@ -134,7 +134,7 @@ Object result = retryTemplate.execute(new RetryCallback() { public Object doWithRetry(RetryContext context) throws Throwable { // do some processing return result; - } + } }); +--- @@ -173,13 +173,13 @@ Object result = retryTemplate.execute(new RetryCallback() { where the current item being processed is a message. This can be generalised to more generic data types, as long as the item can be rejected transactionally to signal that we require it to be - re-delivered to this or another consumer. + re-delivered to this or another consumer. Consider this pattern, which is very typical: +--- 1 | SESSION { -2 | receive; +2 | receive; 3 | RETRY { | remote access; | } @@ -192,7 +192,7 @@ Object result = retryTemplate.execute(new RetryCallback() { +--- 0 | RETRY { // Do not do this! 1 | SESSION { -2 | receive; +2 | receive; 3 | RETRY { | remote access; | } @@ -231,7 +231,7 @@ Object result = retryTemplate.execute(new RetryCallback() { Decisions (3.1) and (5.1) require knowledge of the history of processing the current message. Note that the action on failure is - the opposite to the vanilla case {{{#retry}above}} - if the retry + the opposite to the vanilla case {{{Implementation}above}} - if the retry limit is not reached then we rethrow the exception. If the retry limit is not reached then the rethrow(5.3) causes the diff --git a/src/site/apt/cases/simple.apt b/src/site/apt/cases/simple.apt index 72488aa3b..b24c77233 100644 --- a/src/site/apt/cases/simple.apt +++ b/src/site/apt/cases/simple.apt @@ -27,7 +27,7 @@ Use Case: Simple Batch Repeat * Is stateless - this is not a framework restriction in principle, but simplifies the implementation for now. See in the - {{{#store}Implementation}} section below for some notes on + {{{store}Implementation}} section below for some notes on stateful synchronisation; * Should be implementable as a POJO if desired. @@ -208,7 +208,7 @@ public class RepeatTemplate implements RepeatOperations { // set up the batch interceptors.open(); - + while (running) { // allow interceptor to pre-process and veto continuation @@ -255,7 +255,7 @@ public class RepeatTemplate implements RepeatOperations { // set up the batch session RepeatContext context = completionPolicy.start(); - + while (!completionPolicy.isComplete(context)) { // callback gets the context as an argument diff --git a/src/site/apt/cases/steps.apt b/src/site/apt/cases/steps.apt index cce7226e1..c0340464b 100644 --- a/src/site/apt/cases/steps.apt +++ b/src/site/apt/cases/steps.apt @@ -26,7 +26,7 @@ Use Case: Sequential Processing of Dependent Steps * Preconditions - * A non-trivial sequence is defined: + * A non-trivial sequence is defined: * more than one step: @@ -67,7 +67,7 @@ Use Case: Sequential Processing of Dependent Steps [[1]] Client instructs Framework to store internal state needed by further steps (e.g. cached reference data). - [[1]] Framework logs successful completion of step, and stores + [[1]] Framework logs successful completion of step, and stores [[1]] Repeat for next and subsequent steps. Internal state is passed from one state to the next. @@ -123,10 +123,10 @@ Use Case: Sequential Processing of Dependent Steps introduction of a batch context concept. And the need for initialising restarts leads to the context being serializable, either natively or by some pluggable strategy (this is covered in - the {{{restart.html}Restart after Failure}} use case). + the {{{./restart.html}Restart after Failure}} use case). - Unfortunately, the need for {{{parallel.html}parallel processing}} - and automatic {{{restart.html}restart}} also makes it practically + Unfortunately, the need for {{{./parallel.html}parallel processing}} + and automatic {{{./restart.html}restart}} also makes it practically impossible for steps to handle the context at the level of a single thread of execution, where the client needs to implement business logic. If a step is executing in parallel, then each node needs to @@ -147,7 +147,7 @@ Use Case: Sequential Processing of Dependent Steps object as an argument): +--- -batchTemplate.iterate(new RepeatCallback[] { +batchTemplate.iterate(new RepeatCallback[] { new RepeatCallback() { public boolean doInIteration(RepeatContext context) { diff --git a/src/site/apt/downloads.apt b/src/site/apt/downloads.apt index fda5d4695..7efddbd79 100644 --- a/src/site/apt/downloads.apt +++ b/src/site/apt/downloads.apt @@ -15,7 +15,7 @@ For runtime concerns and a container for running a Job as a service see the {{{h There is a ZIP artifact containing the release JARs called <<>>. This file contains the JAR files for the release, including source code and the samples. - * Full releases: {{{http://static.springframework.org/downloads/nightly/release-download.php?project=BATCH}here}}. + * Full releases: {{{http://static.springframework.org/downloads/nightly/release-download.php?project=BATCH}here}}. * Milestones: {{{http://static.springframework.org/downloads/nightly/milestone-download.php?project=BATCH}here}}. @@ -80,7 +80,7 @@ Source code can also be browsed and downloaded at {{{http://github.com/SpringSou * Milestone Builds - These builds are provided for evaluation and community feedback. Spring Batch builds have a release identifier ending in "MX" where X is the milestone number, or "RCX" for a release candidate (older builds have "mX" and "rcX"). + These builds are provided for evaluation and community feedback. Spring Batch builds have a release identifier ending in "MX" where X is the milestone number, or "RCX" for a release candidate (older builds have "mX" and "rcX"). You can find the .ZIP downloads of the milestones {{{http://static.springframework.org/downloads/nightly/milestone-download.php?project=BATCH}here}}. @@ -130,4 +130,4 @@ Source code can also be browsed and downloaded at {{{http://github.com/SpringSou Snapshot Builds - Nightly snapshots are available through the same process with slightly different URLs. See {{{snapshots.html}here}} for details. + Nightly snapshots are available through the same process with slightly different URLs. See {{{./snapshots.html}here}} for details. diff --git a/src/site/apt/features.apt b/src/site/apt/features.apt index f11cd38a5..0c730f59d 100644 --- a/src/site/apt/features.apt +++ b/src/site/apt/features.apt @@ -7,7 +7,7 @@ Spring Batch Features and Roadmap - See also {{{migration/2.0-highlights.html}details of main themes of 2.0}}. + See also {{{./migration/2.0-highlights.html}details of main themes of 2.0}}. * 2.0 Features @@ -18,7 +18,7 @@ Spring Batch Features and Roadmap * RepeatOperations: an abstraction for grouping repeated operations together and moving the iteration logic into the framework. - + * RetryOperations: an abstraction for automatic retry. * ItemReader abstraction and implementations for flat files, xml @@ -26,7 +26,7 @@ Spring Batch Features and Roadmap * Flat files are supported with fixed length and delimited records (input and ouput). - + * Xml is supported through Spring OXM mapping between objects and Xml elements (input and ouput). Large files are streamed, not read as a whole. diff --git a/src/site/apt/getting-started.apt b/src/site/apt/getting-started.apt index 8bc036f30..dc2a8269d 100644 --- a/src/site/apt/getting-started.apt +++ b/src/site/apt/getting-started.apt @@ -7,7 +7,7 @@ Spring Batch Getting Started - A convenient way to get started quickly with Spring Batch is to run the samples which are packaged in the samples module. There is also a simple command line sample (or "archetype") which has a bare bones but complete implementation of a simpel job. The source code for the samples (and the other modules) is available either from the {{{downloads.html}.Zip assembly}} or from {{{source-repository.html}Git}}. + A convenient way to get started quickly with Spring Batch is to run the samples which are packaged in the samples module. There is also a simple command line sample (or "archetype") which has a bare bones but complete implementation of a simpel job. The source code for the samples (and the other modules) is available either from the {{{./downloads.html}.Zip assembly}} or from {{{source-repository.html}Git}}. * Using SpringSource Tool Suite (STS) @@ -37,7 +37,7 @@ Spring Batch Getting Started * Import the samples and archetype projects from the samples sub-directory in the directory you just unpacked. - * The project should build cleanly without having to fix the dependencies. If it doesn't, make sure you are online, and maybe try building on the command line first to make sure all the dependencies are downloaded. See the {{{building.html}building instructions}} if you run into difficulty. + * The project should build cleanly without having to fix the dependencies. If it doesn't, make sure you are online, and maybe try building on the command line first to make sure all the dependencies are downloaded. See the {{{./building.html}building instructions}} if you run into difficulty. (N.B. the "archetype" is not a real Maven archetype, just a template project that can be used as a starting point for a self-contained batch job. It is the same project that can be imported into STS using the Project Template wizard.) @@ -63,7 +63,7 @@ $ mvn test * Import the <<>> project from the samples directory. - * Find all the compile scope and non-optional runtime jar files listed in the {{{spring-batch-core/dependencies.html}core dependencies report}} and {{{spring-batch-infrastructure/dependencies.html}infrastructure dependencies report}}, and import them into the project. + * Find all the compile scope and non-optional runtime jar files listed in the {{{./spring-batch-core/dependencies.html}core dependencies report}} and {{{./spring-batch-infrastructure/dependencies.html}infrastructure dependencies report}}, and import them into the project. * Force the workspace to build (e.g. Project -> Clean...) @@ -75,11 +75,11 @@ $ mvn test * Using Maven and Git - * Check out the Spring Batch project from Git (instructions are available {{{source-repository.html}here}}). + * Check out the Spring Batch project from Git (instructions are available {{{./source-repository.html}here}}). - * Run Maven from the command line in the samples directory. There are additional building instructions and suggestions about what to do if it goes wrong {{{building.html}here}}. + * Run Maven from the command line in the samples directory. There are additional building instructions and suggestions about what to do if it goes wrong {{{./building.html}here}}. * Using Gradle (for Groovy programmers) * There is a Groovy project template with instructions available {{{http://robokaso.github.com/Groovy-Spring-Batch-Template/}here}} - + diff --git a/src/site/apt/index.apt b/src/site/apt/index.apt index 741803a5c..63c986b43 100644 --- a/src/site/apt/index.apt +++ b/src/site/apt/index.apt @@ -6,15 +6,15 @@ March 2007, May 2007 Introduction - + Many applications within the enterprise domain require bulk processing to perform business operations in mission critical environments. These business operations include automated, complex processing of large volumes of information that is most efficiently processed without user interaction. These operations typically include time based events (e.g. month-end calculations, notices or correspondence), periodic application of complex business rules processed repetitively across very large data sets (e.g. insurance benefit determination or rate adjustments), or the integration of information that is received from internal and external systems that typically requires formatting, validation and processing in a transactional manner into the system of record. Batch processing is used to process billions of transactions every day for enterprises. - - Spring Batch is a lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems. Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary. - + + Spring Batch is a lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems. Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary. + Spring Batch provides reusable functions that are essential in processing large volumes of records, including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management. It also provides more advanced technical services and features that will enable extremely high-volume and high performance batch jobs through optimization and partitioning techniques. Simple as well as complex, high-volume batch jobs can leverage the framework in a highly scalable manner to process significant volumes of information. Spring Batch is part of {{{http://www.springframework.org/projects}Spring}}. For runtime concerns and a container for running a Job as a service see the {{{http://static.springframework.org/spring-batch-admin}Spring Batch Admin}} project. - + * Spring Batch Architecture Spring Batch is designed with extensibility and a diverse group of end users in mind. The figure below shows a sketch of the layered architecture that supports the extensibility and ease of use for end-user developers. @@ -22,10 +22,10 @@ Introduction [images/ExecutionEnvironment.png] Spring Batch Architecture showing Infrastructure and Execution Layers. Potential execution strategy implementations support different platforms and end-user goals from the same blocks of business logic in the Application Layer. Spring Batch provides an Infrastructure layer in the form of low level tools. There is also a simple execution environment, using the infrastructure in its implementation. The execution environment provides robust features for traceability and management of the batch lifecycle. A key goal is that the management of the batch process (locating a job and its input, starting, scheduling, restarting, and finally processing to created results) should be as easy as possible for developers. - + The Infrastructure provides the ability to batch operations together, and to retry an piece of work if there is an exception. Both requirements have a transactional flavour, and similar concepts are relevant (propagation, synchronisation). They also both lend themselves to the template programming model common in Spring, c.f. <<>>, <<>>, <<>>. - - The Core module is the batch-focused domain and implementation. It provides a robust set of integrated features including job processing statistics, job launch and restart to enable the management of the full lifecycle of traditional batch processing. + + The Core module is the batch-focused domain and implementation. It provides a robust set of integrated features including job processing statistics, job launch and restart to enable the management of the full lifecycle of traditional batch processing. A number of sample jobs are packaged in a separate Samples module to more clearly articulate the usage and capabilities of the Core module. @@ -35,12 +35,12 @@ Introduction * Roadmap - The current production release version is specified {{{downloads.html}here}}, and links are also provided to the latest development work. + The current production release version is specified {{{./downloads.html}here}}, and links are also provided to the latest development work. The framework is oriented around application developers not needing to know any details of the framework - there are a few application developer interfaces that can be used for convenient construction of data processing pipelines, but apart from that we support as close to a POJO programming model as is practical. This is similar to the approach taken in Spring Core in the area of DAO implementation. Spring Batch version 1.x was targeted at Java 1.4 and single-process, possibly multi-threaded execution. Spring Batch 2.0 is a Java 5 only release, using all available language features with no compromises for backward compatibility with Java 2. We think this will provide a significantly improved programming model for batch application developers. - + Framework tools for scaling to multiple processes are available in Spring Batch 2.0. These provide advanced technical services and features to enable extremely high-volume and high performance batch jobs though proven optimization and clustering techniques. An SPI is provided with a simple implementation that works in a single process (multi-threaded). Various remoting and grid technologies can be used to implement the same SPI in a multi-process, clustered environment. Matt Welsh's work shows that {{{http://www.eecs.harvard.edu/~mdw/proj/seda/}SEDA}} has enormous benefits over more rigid processing architectures, and messaging environments give us a lot of resilience out of the box. So we also want to enable a more SEDA flavoured execution environments, as well as supporting the more traditional ETL style approach. The key to unlocking the programming model is {{{http://www.springframework.org/spring-integration}Spring Integration}}, where the choice of transport and distribution strategy can be made as late as possible. The key to the runtime requirements of deployment and manageability is going to be with the {{{http://www.springsource.com/products/suite/applicationplatform}SpringSource Application Platform}}. The same application code could be used in principle for a standalone tool processing a small amount of data, and a massive enterprise-scale bulk-processing engine. @@ -48,10 +48,10 @@ Introduction * Background While open source software projects and associated communities have focused greater attention on web-based and SOA messaging-based architecture frameworks, there has been a notable lack of focus on reusable architecture frameworks to accommodate Java-based batch processing needs, despite continued needs to handle such processing within enterprise IT environments. The lack of a standard, reusable batch architecture has resulted in the proliferation of many one-off, in-house solutions developed within client enterprise IT functions. - - SpringSource and Accenture are collaborating to change this. Accenture's hands-on industry and technical experience in implementing batch architectures, SpringSource's depth of technical experience, and Spring's proven programming model together mark a natural and powerful partnership to create high-quality, market relevant software aimed at filling an important gap in enterprise Java. Both companies are also currently working with a number of clients solving similar problems developing Spring-based batch architecture solutions. This has provided some useful additional detail and real-life constraints helping to ensure the solution can be applied to the real-world problems posed by clients. For these reasons and many more, SpringSource and Accenture have teamed to collaborate on the development of Spring Batch. - - Accenture is contributing previously proprietary batch processing architecture frameworks -- based upon decades worth of experience in building batch architectures with the last several generations of platforms (i.e., COBOL/Mainframe, C++/Unix, and now Java/anywhere) -- to the Spring Batch project along with committer resources to drive support, enhancements, and the future roadmap. - - The collaborative effort between Accenture and SpringSource aims to promote the standardization of software processing approaches, frameworks, and tools that can be consistently leveraged by enterprise users when creating batch applications. Companies and government agencies desiring to deliver standard, proven solutions to their enterprise IT environments will benefit from Spring Batch. + + SpringSource and Accenture are collaborating to change this. Accenture's hands-on industry and technical experience in implementing batch architectures, SpringSource's depth of technical experience, and Spring's proven programming model together mark a natural and powerful partnership to create high-quality, market relevant software aimed at filling an important gap in enterprise Java. Both companies are also currently working with a number of clients solving similar problems developing Spring-based batch architecture solutions. This has provided some useful additional detail and real-life constraints helping to ensure the solution can be applied to the real-world problems posed by clients. For these reasons and many more, SpringSource and Accenture have teamed to collaborate on the development of Spring Batch. + + Accenture is contributing previously proprietary batch processing architecture frameworks -- based upon decades worth of experience in building batch architectures with the last several generations of platforms (i.e., COBOL/Mainframe, C++/Unix, and now Java/anywhere) -- to the Spring Batch project along with committer resources to drive support, enhancements, and the future roadmap. + + The collaborative effort between Accenture and SpringSource aims to promote the standardization of software processing approaches, frameworks, and tools that can be consistently leveraged by enterprise users when creating batch applications. Companies and government agencies desiring to deliver standard, proven solutions to their enterprise IT environments will benefit from Spring Batch. diff --git a/src/site/apt/migration/2.1.9-2.2.0.M1.apt b/src/site/apt/migration/2.1.9-2.2.0.M1.apt new file mode 100644 index 000000000..5d908a254 --- /dev/null +++ b/src/site/apt/migration/2.1.9-2.2.0.M1.apt @@ -0,0 +1,65 @@ +Spring Batch 2.2.0.M1 Release Notes + +* Bug + + * {{{https://jira.springframework.org/browse/BATCH-1745}[BATCH-1745]}} - XSD inconsistency: allow-start-if-complete is not allowed on non-tasklet step + + * {{{https://jira.springframework.org/browse/BATCH-1773}[BATCH-1773]}} - Step-scoped annotation based listener is not called + + * {{{https://jira.springframework.org/browse/BATCH-1774}[BATCH-1774]}} - NullPointerException on RepeateTemplate + + * {{{https://jira.springframework.org/browse/BATCH-1780}[BATCH-1780]}} - Code exception is masked by a batch exception + + * {{{https://jira.springframework.org/browse/BATCH-1799}[BATCH-1799]}} - Exception in flush of file output ItemWriters does not abort a step/job + + * {{{https://jira.springframework.org/browse/BATCH-1903}[BATCH-1903]}} - SQL compatibility breakage with HSQL + + * {{{https://jira.springframework.org/browse/BATCH-1916}[BATCH-1916]}} - RecordSeparatorPolicy#isEndOfRecord wrong javadoc? + + * {{{https://jira.springframework.org/browse/BATCH-1920}[BATCH-1920]}} - Add sample for new AMQPItemReader & Writer + + * {{{https://jira.springframework.org/browse/BATCH-1950}[BATCH-1950]}} - Fix bootstrap process + +* Improvement + + * {{{https://jira.springframework.org/browse/BATCH-1667}[BATCH-1667]}} - StepExecutionListener ExitStatus not persisted and not accessible for other listeners + + * {{{https://jira.springframework.org/browse/BATCH-1691}[BATCH-1691]}} - Allow to define groupBy for SqlPaginingQueryProviderFactoryBean + + * {{{https://jira.springframework.org/browse/BATCH-1854}[BATCH-1854]}} - Create marker interface to be used by MultiResourceItemReader to inject the resource an item was read from. + + * {{{https://jira.springframework.org/browse/BATCH-1889}[BATCH-1889]}} - SqlFire support + + * {{{https://jira.springframework.org/browse/BATCH-1904}[BATCH-1904]}} - Upgrade support of Hibernate to Hibernate 4 + +* New Feature + + * {{{https://jira.springframework.org/browse/BATCH-1666}[BATCH-1666]}} - Add abort(long executionId) convenience method to JobOperator + + * {{{https://jira.springframework.org/browse/BATCH-1684}[BATCH-1684]}} - Allow serializer to be injected into JobRepository (ExecutionContextDao) + + * {{{https://jira.springframework.org/browse/BATCH-1694}[BATCH-1694]}} - Add StepLocatorStepFactoryBean + + * {{{https://jira.springframework.org/browse/BATCH-1714}[BATCH-1714]}} - Change ChunkListener interface and semantics to be called after rollback as well as commit + + * {{{https://jira.springframework.org/browse/BATCH-1749}[BATCH-1749]}} - JdbcPagingItemReader query fails when specifying multiple columns in sortKey + + * {{{https://jira.springframework.org/browse/BATCH-1869}[BATCH-1869]}} - Need a line tokenizer to parse the line based on string (multi character) delimiter than a single character delimiter + + * {{{https://jira.springframework.org/browse/BATCH-1911}[BATCH-1911]}} - Provide a Step registry to be able to locate a step by its name on (namely) remote nodes + + * {{{https://jira.springframework.org/browse/BATCH-1935}[BATCH-1935]}} - Add quick start maven archetype + +* Task + + * {{{https://jira.springframework.org/browse/BATCH-1938}[BATCH-1938]}} - Update to support Spring 3.2.0.RELEASE + + * {{{https://jira.springframework.org/browse/BATCH-1943}[BATCH-1943]}} - Add ChunkContext to existing ChunkListener methods + +* Refactoring + + * {{{https://jira.springframework.org/browse/BATCH-1915}[BATCH-1915]}} - Change minimum compiler level to 1.6 and use @Override everywhere + + * {{{https://jira.springframework.org/browse/BATCH-1940}[BATCH-1940]}} - Replace org.springframework.batch.support.JdbcTestUtils with org.springframework.test.jdbc.JdbcTestUtils + + * {{{https://jira.springframework.org/browse/BATCH-1949}[BATCH-1949]}} - Remove explicit checks for Spring 3 in StepScope diff --git a/src/site/apt/migration/index.apt b/src/site/apt/migration/index.apt index 82419e730..04bd86601 100644 --- a/src/site/apt/migration/index.apt +++ b/src/site/apt/migration/index.apt @@ -6,88 +6,90 @@ September 2009 See the changes report generated from {{{issue-tracking.html}JIRA}}. - + There is a pre-built {{{http://opensource.atlassian.com/projects/spring/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10090&status=5&status=6&updated:previous=-1w&sorter/field=updated&sorter/order=DESC}Resolved Recently}} query that might be useful. - + You can also browse the upcoming releases and look at the {{{http://opensource.atlassian.com/projects/spring/browse/BATCH?report=com.atlassian.jira.plugin.system.project:roadmap-panel}Road Map}} query. Links: - * {{{2.1.8-2.1.9.html}2.1.8 to 2.1.9}} + * {{{./2.1.9-2.2.0.M1.html}2.1.9-2.2.0.M1}} - * {{{2.1.7-2.1.8.html}2.1.7 to 2.1.8}} + * {{{./2.1.8-2.1.9.html}2.1.8 to 2.1.9}} - * {{{2.1.6-2.1.7.html}2.1.6 to 2.1.7}} + * {{{./2.1.7-2.1.8.html}2.1.7 to 2.1.8}} - * {{{2.1.5-2.1.6.html}2.1.5 to 2.1.6}} + * {{{./2.1.6-2.1.7.html}2.1.6 to 2.1.7}} - * {{{2.1.4-2.1.5.html}2.1.4 to 2.1.5}} + * {{{./2.1.5-2.1.6.html}2.1.5 to 2.1.6}} - * {{{2.1.3-2.1.4.html}2.1.3 to 2.1.4}} + * {{{./2.1.4-2.1.5.html}2.1.4 to 2.1.5}} - * {{{2.1.2-2.1.3.html}2.1.2 to 2.1.3}} + * {{{./2.1.3-2.1.4.html}2.1.3 to 2.1.4}} - * {{{2.1.1-2.1.2.html}2.1.1 to 2.1.2}} + * {{{./2.1.2-2.1.3.html}2.1.2 to 2.1.3}} - * {{{2.1.0-2.1.1.html}2.1.0 to 2.1.1}} + * {{{./2.1.1-2.1.2.html}2.1.1 to 2.1.2}} - * {{{2.1.0.RC1-2.1.0.html}2.1.0.RC1 to 2.1.0}} + * {{{./2.1.0-2.1.1.html}2.1.0 to 2.1.1}} - * {{{2.1.0.M4-2.1.0.RC1.html}2.1.0.M4 to 2.1.0.RC1}} + * {{{./2.1.0.RC1-2.1.0.html}2.1.0.RC1 to 2.1.0}} - * {{{2.1.0.M3-2.1.0.M4.html}2.1.0.M3 to 2.1.0.M4}} + * {{{./2.1.0.M4-2.1.0.RC1.html}2.1.0.M4 to 2.1.0.RC1}} - * {{{2.1.0.M2-2.1.0.M3.html}2.1.0.M2 to 2.1.0.M3}} + * {{{./2.1.0.M3-2.1.0.M4.html}2.1.0.M3 to 2.1.0.M4}} - * {{{2.1.0.M1-2.1.0.M2.html}2.1.0.M1 to 2.1.0.M2}} + * {{{./2.1.0.M2-2.1.0.M3.html}2.1.0.M2 to 2.1.0.M3}} - * {{{2.1.0.M1-2.1.0.M2.html}2.1.0.M1 to 2.1.0.M2}} + * {{{./2.1.0.M1-2.1.0.M2.html}2.1.0.M1 to 2.1.0.M2}} - * {{{2.0.x-2.1.0.M1.html}2.0.x to 2.1.0.M1}} + * {{{./2.1.0.M1-2.1.0.M2.html}2.1.0.M1 to 2.1.0.M2}} - * {{{2.0-highlights.html}Highlights of changes between 1.x and 2.0}} - - * {{{2.0.3-2.0.4.html}2.0.3.RELEASE to 2.0.4.RELEASE}} + * {{{./2.0.x-2.1.0.M1.html}2.0.x to 2.1.0.M1}} - * {{{2.0.2-2.0.3.html}2.0.2.RELEASE to 2.0.3.RELEASE}} + * {{{./2.0-highlights.html}Highlights of changes between 1.x and 2.0}} - * {{{2.0.1-2.0.2.html}2.0.1.RELEASE to 2.0.2.RELEASE}} + * {{{./2.0.3-2.0.4.html}2.0.3.RELEASE to 2.0.4.RELEASE}} - * {{{2.0.0-2.0.1.html}2.0.0.RELEASE to 2.0.1.RELEASE}} + * {{{./2.0.2-2.0.3.html}2.0.2.RELEASE to 2.0.3.RELEASE}} - * {{{2.0-rc3-release.html}2.0.0.RC3 to 2.0.0.RELEASE}} + * {{{./2.0.1-2.0.2.html}2.0.1.RELEASE to 2.0.2.RELEASE}} - * {{{2.0-rc2-rc3.html}2.0.0.RC2 to 2.0.0.RC3}} + * {{{./2.0.0-2.0.1.html}2.0.0.RELEASE to 2.0.1.RELEASE}} - * {{{2.0-rc1-rc2.html}2.0.0.RC1 to 2.0.0.RC2}} + * {{{./2.0-rc3-release.html}2.0.0.RC3 to 2.0.0.RELEASE}} - * {{{2.0-m4-rc1.html}2.0.0.M4 to 2.0.0.RC1}} + * {{{./2.0-rc2-rc3.html}2.0.0.RC2 to 2.0.0.RC3}} - * {{{2.0-m3-m4.html}2.0.0.M3 to 2.0.0.M4}} + * {{{./2.0-rc1-rc2.html}2.0.0.RC1 to 2.0.0.RC2}} - * {{{2.0-m2-m3.html}2.0.0.M2 to 2.0.0.M3}} + * {{{./2.0-m4-rc1.html}2.0.0.M4 to 2.0.0.RC1}} - * {{{2.0-m1-m2.html}2.0.0.M1 to 2.0.0.M2}} + * {{{./2.0-m3-m4.html}2.0.0.M3 to 2.0.0.M4}} - * {{{1.1-2.0-m1.html}1.1 to 2.0.0.M1}} + * {{{./2.0-m2-m3.html}2.0.0.M2 to 2.0.0.M3}} - * {{{1.1.2-1.1.3.html}1.1.2 to 1.1.3}} - - * {{{1.1.1-1.1.2.html}1.1.1 to 1.1.2}} - - * {{{1.1-1.1.1.html}1.1 to 1.1.1}} + * {{{./2.0-m1-m2.html}2.0.0.M1 to 2.0.0.M2}} - * {{{1.0.1-1.1.html}1.0.1 to 1.1}} + * {{{./1.1-2.0-m1.html}1.1 to 2.0.0.M1}} - * {{{1.0.0-1.0.1.html}1.0.0 to 1.0.1}} + * {{{./1.1.2-1.1.3.html}1.1.2 to 1.1.3}} - * {{{1.0-rc1-final.html}1.0 rc1 to final}} + * {{{./1.1.1-1.1.2.html}1.1.1 to 1.1.2}} - * {{{1.0-m5-rc1.html}1.0 m5 to rc1}} + * {{{./1.1-1.1.1.html}1.1 to 1.1.1}} - * {{{1.0-m4-m5.html}1.0 m4 to m5}} + * {{{./1.0.1-1.1.html}1.0.1 to 1.1}} - * {{{1.0-m3-m4.html}1.0 m3 to m4}} + * {{{./1.0.0-1.0.1.html}1.0.0 to 1.0.1}} + + * {{{./1.0-rc1-final.html}1.0 rc1 to final}} + + * {{{./1.0-m5-rc1.html}1.0 m5 to rc1}} + + * {{{./1.0-m4-m5.html}1.0 m4 to m5}} + + * {{{./1.0-m3-m4.html}1.0 m3 to m4}} + + * {{{./1.0-m2-m3.html}1.0 m2 to m3}} - * {{{1.0-m2-m3.html}1.0 m2 to m3}} - diff --git a/src/site/apt/reference/index.apt b/src/site/apt/reference/index.apt index 854c076ee..e42f04ceb 100644 --- a/src/site/apt/reference/index.apt +++ b/src/site/apt/reference/index.apt @@ -11,10 +11,10 @@ Spring Batch Documentation This is the home of the Spring Batch Reference Guide. This is where you can find out how to use Spring Batch and how the pieces fit together. For detailed descriptions of the individual classes in Spring Batch please refer to the {{{../apidocs/index.html}Javadocs}}. There is also a separate section of this web site for the {{{../spring-batch-samples/index.html}Spring Batch Samples}}. If you want to get started quickly that might be a good place to start. Use the links below to navigate to the HTML and PDF versions of the guide: - - * {{{html/index.html}HTML}} format - - * {{{html-single/index.html}HTML Single Page}} - - * {{{pdf/spring-batch-docs.pdf}PDF}} format + + * {{{./html/index.html}HTML}} format + + * {{{./html-single/index.html}HTML Single Page}} + + * {{{./pdf/spring-batch-docs.pdf}PDF}} format diff --git a/src/site/apt/transactions.apt b/src/site/apt/transactions.apt index 1a1b75915..4ce3b746d 100644 --- a/src/site/apt/transactions.apt +++ b/src/site/apt/transactions.apt @@ -16,14 +16,14 @@ Batch Processing and Transactions +--- 1 | REPEAT(until=exhausted) { - | + | 2 | TX { 3 | REPEAT(size=5) { -3.1 | input; +3.1 | input; 3.2 | output; | } | } - | + | | } +--- @@ -44,7 +44,7 @@ Batch Processing and Transactions +--- 0 | TX { -1 | input; +1 | input; 1.1 | output; 2 | RETRY { 2.1 | remote access; @@ -62,12 +62,12 @@ Batch Processing and Transactions * {Typical} Repeat-Retry Pattern The most typical batch processing pattern is to add a retry to the - inner block of the chunk in the {{{#Simple Batching}simple}} example. + inner block of the chunk in the {{{Simple Batching}simple}} example. Consider this: +--- 1 | REPEAT(until=exhausted, exception=not critical) { - | + | 2 | TX { 3 | REPEAT(size=5) { | @@ -86,7 +86,7 @@ Batch Processing and Transactions +--- The inner RETRY(4) block is marked as "stateful" - see the - {{{#Typical}typical}} use case for a description of a stateful + {{{Typical}typical}} use case for a description of a stateful retry. This means that if the the retry PROCESS(5) block fails, the behaviour of the RETRY(4) is as follows. @@ -115,7 +115,7 @@ Batch Processing and Transactions type), the retry policy might be able to determine that the RECOVER(6) path can be taken on the last attempt after PROCESS(5) has just failed, instead of waiting for the item to be re-presented. - This is not the default behaviour because it requires detailed + This is not the default behavior because it requires detailed knowledge of what has happened inside the PROCESS(5) block, which is not usually available - e.g. if the output included write access before the failure, then the exception should be rethrown to @@ -136,7 +136,7 @@ Batch Processing and Transactions implementation of the input(4.1). Thus the output(5.1) might fail again, on a new item, or on the old one. The client of the batch should not assume that each RETRY(4) attempt is going to process the - same items as the last on ethat failed. E.g. if the termination + same items as the last one that failed. E.g. if the termination policy for REPEAT(1) is to fail after 10 attempts, it will fail after 10 consecutive attempts, but not necessarily at the same item. This is consistent with the overall retry strategy: it is the inner @@ -145,14 +145,14 @@ Batch Processing and Transactions * Asynchronous Chunk Processing - The inner batches or chunks in the {{{#Typical}typical}} example + The inner batches or chunks in the {{{Typical}typical}} example above can be executed concurrently by configuring the outer batch to use an <<>>. The outer batch waits for all the chunks to complete before completing. +--- 1 | REPEAT(until=exhausted, concurrent, exception=not critical) { - | + | 2 | TX { 3 | REPEAT(size=5) { | @@ -166,20 +166,20 @@ Batch Processing and Transactions | | } | } - | + | | } +--- * Asynchronous Item Processing - The individual items in chunks in the {{{#Typical}typical}} + The individual items in chunks in the {{{Typical}typical}} can also in principle be processed concurrently. In this case the transaction boundary has to move to the level of the individual item, so that each transaction is on a single thread: +--- 1 | REPEAT(until=exhausted, exception=not critical) { - | + | 2 | REPEAT(size=5, concurrent) { | 3 | TX { @@ -193,7 +193,7 @@ Batch Processing and Transactions | } | | } - | + | | } +--- @@ -213,15 +213,15 @@ Interactions Between Batching and Transaction Propagation +--- 1 | TX { - | -1.1 | input; + | +1.1 | input; 2.2 | database access; 2 | RETRY { 3 | TX { 3.1 | database access; | } | } - | + | | } +--- @@ -234,9 +234,9 @@ Interactions Between Batching and Transaction Propagation +--- 1 | TX { - | + | 2 | REPEAT(size=5) { -2.1 | input; +2.1 | input; 2.2 | database access; 3 | RETRY { 4 | TX { @@ -244,7 +244,7 @@ Interactions Between Batching and Transaction Propagation | } | } | } - | + | | } +--- @@ -280,7 +280,7 @@ Interactions Between Batching and Transaction Propagation +--- 0 | SESSION { -1 | input; +1 | input; 2 | RETRY { 3 | TX { 3.1 | database access; @@ -303,7 +303,7 @@ Interactions Between Batching and Transaction Propagation * Stateless Retry Cannot Recover The distinction between a stateless and a stateful retry in the - {{{#Typical}typical}} example above is important. It is actually + {{{Typical}typical}} example above is important. It is actually ultimately a transactional constraint that forces the distinction, and this constraint also makes it obvious why the distinction exists. @@ -311,17 +311,17 @@ Interactions Between Batching and Transaction Propagation We start with the observation that there is no way to skip an item that failed and successfully commit the rest of the chunk unless we wrap the item processing in a transaction. So we simplify the - {{{#Typical}typical}} batch execution plan to look like this: + {{{Typical}typical}} batch execution plan to look like this: +--- 0 | REPEAT(until=exhausted) { - | + | 1 | TX { 2 | REPEAT(size=5) { | 3 | RETRY(stateless) { 4 | TX { -4.1 | input; +4.1 | input; 4.2 | database access; | } 5 | } RECOVER { @@ -330,7 +330,7 @@ Interactions Between Batching and Transaction Propagation | | } | } - | + | | } +--- @@ -349,6 +349,6 @@ Interactions Between Batching and Transaction Propagation not to support recovery with stateless retries in current versions of Spring Batch. The same effect can always be achieved (at the expense of repeating more processing) using the - {{{#Typical}typical}} pattern above. + {{{Typical}typical}} pattern above. diff --git a/src/site/docbook/reference/index.xml b/src/site/docbook/reference/index.xml index 81651b5fb..1889938ef 100644 --- a/src/site/docbook/reference/index.xml +++ b/src/site/docbook/reference/index.xml @@ -5,7 +5,7 @@ Spring Batch - Reference Documentation - Spring Batch 2.1.8 + Spring Batch 2.2.0.M1 @@ -37,6 +37,11 @@ Lund + + Michael + Minella + +