diff --git a/docs/models/spring-batch-reference-model.png b/docs/models/spring-batch-reference-model.png new file mode 100755 index 000000000..ae1ff22ef Binary files /dev/null and b/docs/models/spring-batch-reference-model.png differ diff --git a/docs/src/site/docbook/reference/core.xml b/docs/src/site/docbook/reference/core.xml index 6af6ee987..78a4ab822 100644 --- a/docs/src/site/docbook/reference/core.xml +++ b/docs/src/site/docbook/reference/core.xml @@ -655,9 +655,19 @@ - + commitCount - + The number of times the transaction has been committed + for this execution + + + + itemCount + + The number of items that have been process for this + execution. It should be noted that this value will continue + increasing even if a rollback causes items to be + reprocessed. @@ -669,89 +679,33 @@ A Tasklet represents the execution of a logical unit of work, as defined by its implementation of the Spring - Batch provided Tasklet interface. Tasklets are - used when defining step configurations to specify the work done by the - step. Subsequently, the logic in a tasklet is atomic in terms of - transactions. A transaction will never commit until an entire tasklet - execution is complete (unless an exception occurs - a transaction might - either commit or rollback if that behavior is specified in the step's - exception management strategy). There is a specific implementation of - the Step interface, TaskletStep, that works directly with a - Tasklet. + Batch provided Tasklet interface. A + Tasklet is useful for encapsulating processing + logic that is not natural to split into read-(transform)-write phases, + such as invoking a system command or a stored procedure.
- Item-Oriented Processing Stereotypes + Item Reader - A powerful batch processing paradigm implemented by the Spring Batch - framework is the concept of item-oriented processing. That is, doing work - by defining each unit of work as the operation of retrieving an item from - input and then processing that item, including any side effects that - processing might entail, such as file or database operations. - -
- Reader and Writer Stereotypes - - There are two basic stereotypes that represent the first-class - participants in item-oriented processing, item providers and item - processors. They are each represented by a simple interface provided by - the Spring Batch framework, which allows free reign over their - implementations and improves our ability to leverage the Spring - framework's dependency injection capabilities. - -
- Item Readers - - An item reader is an object that is used to retrieve the inputs - for a step, one at a time. When the item reader has exhausted the - items it can provide, it will indicate this in a meaningful way - (generally by returning null). When coupled with an item processor, - this forms a complete item-oriented process, as each item taken from - the provider is then processed by the writer. -
- -
- Item Writers/Processors - - An item writer is an object that is used to perform processing - for a step, one item at a time. Generally, an item writer has no - knowledge of the input it will receive next, only the item that that - was passed in its current invocation. As a result, item writers will - generally make no assumptions about the input they receive an treat - every item the same way and keep track of its own state between - invocations. When coupled with an item provider, this forms a complete - item-oriented process, as each item taken from the provider is then - processed by the processor. -
-
+ ItemReader is an abstraction that represents + the retrieval of input for a Step, one item at a + time. When the ItemReader has exhausted the items + it can provide, it will indicate this by returning null. More details + about the ItemReader interface and it's various + implementatiosn can be found in Chapter 3.
- Support Stereotypes + Item Writer - While item readers and writers serve as the main entry points for - item-oriented processing, they might be supplemented by a number of - support classes that perform specific tasks within the reader / writer - lifecycle. These support stereotypes are useful for dividing the work of - item readers and writers into reusable pieces, as well as abstracting away - the details of processing, such as interaction with external systems. - Additionally, they give us another opportunity to leverage the powerful - configuration features of the Spring framework, as we can switch between - several beans implementing these support interfaces without changing the - driving item reader or writer. - -
- Item Transformers - - An item transformer is a class that is capable of taking an object - and changing it somehow before processing occurs. For instance, an item - transformer my alter an object by changing its properties or by - replacing it with another object entirely, such as a wrapper or - derivative object. It can also be defined as an adaptor, allowing an - object of one type to be converted for use as an object of a second - type. -
+ ItemWriter is an abstraction that represents + the output of a Step, one item at a time. + Generally, an item writer has no knowledge of the input it will receive + next, only the item that that was passed in its current invocation. More + details about the ItemWriter interface and it's + various implementations can be found in Chatper 3.
@@ -802,55 +756,58 @@ 4.1 The first thing the Step is responsible for is the initialization of the data required to begin - processing. The Step will interact with other architecture components, - such as the Input Source, to setup the data required to be - processed. + processing. The Step will interact with other + architecture components, such as the ItemReader, to + setup the data required to be processed. - 4.1.1 The Input Source provides - services to access various data sources. It provides location transparency - to the Batch Tasklet and hides the physical location details of the + 4.1.1 The + ItemReader provides services to access various data + sources. It provides location transparency to the Batch + Step and hides the physical location details of the data. 4.2 Once the data is initialized by - the Input Source, the Step will call into the Tasklet to begin processing. - The Tasklet contains the business logic to define the LUW and the Step - repeatedly calls the Tasklets LUW to finish the business function. The - Step does this by first invoking the execute method on the Tasklet in - order to acquire a single record/set of data for processing. + the ItemReader, the Step + will begin processing. 4.2.1 Before a record is returned - to the Tasklet, it may be validated by any number of validation Frameworks - that can be provided to an input source. A single record/set of data is - gathered by interacting with the Input Source. + to the Step, it may be validated by any number of + validation Frameworks that can be provided to an + ItemReader. A single record/set of data is gathered + by interacting with the ItemReader. 4.3 Once a record/set has been - obtained, the step calls the tasklet to begin processing. + obtained, the step calls the + ItemWriter to begin processing. - 4.3.1 The Tasklet executes its - internal business logic by calling other Business Logic components as - necessary. Based on the business service, it requests or persists objects - from the data access components. + 4.3.1 Either an ItemReader or + ItemWriter can execute its internal business logic by calling other + Business Logic components as necessary. Based on the business service, it + requests or persists objects from the data access components. 4.3.3 Data Access components can be leveraged retrieve or persist domain objects. 4.3.4 Once the business logic has been executed, the resulting output record is written out by utilizing the - Output Source interface. The Step will repeatedly call steps 4.2 -> 4.3 - for every record provided by the Input Source. + ItemWriter interface. The + Step will repeatedly call steps 4.2 -> 4.3 for + every record provided by the Input Source. 4.4 Once all of the records are - processed, the Step calls the Tasklet to perform any clean up activities - such as closing connections, exporting files, etc. + processed, the Step closes all streams to perform + any clean up activities such as closing connections, exporting files, + etc. - 4.4.1 The Step is responsible for - committing data associated with the remaining logical units of work as - well as performing any finalization and administrative functions (e.g. - closing database connections). + 4.4.1 The + Step is responsible for committing data associated + with the remaining logical units of work as well as performing any + finalization and administrative functions (e.g. closing database + connections). - Once the Step has completed finalization the control is passed back - to the Job, where any necessary logging or clean up is executed for - application termination and wrap-up -- provided there are no additional - Steps to execute. + Once the Step has completed finalization the + control is passed back to the Job, where any + necessary logging or clean up is executed for application termination and + wrap-up, provided there are no additional Steps to execute.
\ No newline at end of file diff --git a/docs/src/site/resources/reference/images/spring-batch-layers.png b/docs/src/site/resources/reference/images/spring-batch-layers.png new file mode 100644 index 000000000..ff1764074 Binary files /dev/null and b/docs/src/site/resources/reference/images/spring-batch-layers.png differ