Spring Batch Transaction Processing

Transaction Model Description
1, the step between the transaction independent 2, the step divides into the multiple chunk executes, the chunk affairs each other independent, does not affect; Chunk start a transaction, normally end the commit diagram-job the overall transaction diagram-step internal transaction 3,       Chunk definition: The default setting is Commitinterval=n, which reads N data as a chunk (with default simplecompletionpolicy), or item==null read in reader, or satisfies a custom completion policy Transaction Commit & Rollback 1, transaction commit condition: Chunk performs normally, does not throw RuntimeExecption2, by default, Reader, Processor, writer throws an uncaught runtimeexception, The current chunk transaction is rolled back, step fails, job fails 3, the following configuration ensures that when an exception occurs, the transaction does not roll back, and the transaction continues to commit:

<batch:tasklet> <batch:chunk /> <batch:no-rollback-exception-classes> <batch:include class="com.xx.batch.DefRuntimeException"/> </batch:no-rollback-exception-classes> </batch:tasklet>4. Transaction configuration. Change transaction behavior with the following configuration

<batch:tasklet> <batch: transaction-attributes isolation= "read_committed"  propagation= timeout=" /> <batch:chunk reader="defItemReader" processor="defItemProcessor" writer="defItemWriter" commit-interval="10"/> </batch:tasklet>Default configuration: default+requiredParameter configuration Impact 1, Task recovery

<batch:job id="jobId" restartable="true"> </batch:job>By configuring the restartable=true of the job, you ensure that the task fails to recover. For example: When the file is processed, chunksize=10, processing fails at line=35, and after the file is repaired, the job will be re-processed from 31 rows (because 1-10,11-20,21-30 commits the transaction, Spring Batch persists the count in ExecutionContext to the system table, reads on recovery) Flatfileitemreader inherits the Abstractitemcountingitemstreamitemreader class, So the default read recovery capability 2, skip

<batch:chunk skip-limit="20"> <batch:skippable-exception-classes> <batch:include class="com.xx.batch.ExceptionClass" /> </batch:skippable-exception-classes> </batch:chunk>Or

<batch:chunk skip-policy="defSkipPolicy"> </batch:chunk>Skipping the amount of data or skipping a policy when the step fails, the job fails a, the Itemprocessor processing skips the transaction rollback, the failed entry in the cache flag is skipped, and the entry in the transaction cache is reopened and submitted. This time will repeat the process, if there is business logic, pay attention to the idempotent problem B, itemwriter processing skips the transaction rollback, the failure entry in the cache flag is skipped, because it is a batch commit, need to find the problem entry, so for each entry to open a transaction loop processing process &write and Commit, if there is business logic, pay attention to idempotent issues 3, retry

<batch:chunk retry-limit="20"> <batch:retryable-exception-classes> <batch:include class="com.xx.batch.ExceptionClass" /> </batch:retryable-exception-classes> </batch:chunk>Or

<batch:chunk retry-policy="defRetryPolicy"> </batch:chunk>When the retry count is reached or the retry policy is not met, the step fails, the job fails   4, Reader-transactional-queue&processor-transactional a, Reader-transactional-queue, default False, set to TRUE indicates that the read resource has a transactional attribute, and the resource is rolled back when the chunk transaction is rolled back. An exception causes repeated reads and processing, attention to idempotent issues  b, processor-transactional, default True, that is, writer fails, processor repeated execution, you need to pay attention to the power of the problem; set false, That is, when writer fails, processor no longer executes    handles component transactions  spring  batch provides a number of components such as listeners, referring to transaction considerations when dealing with transaction-related issues:      Figure-job Execution phase Track & transaction       Note: Itemreadelistener, Itemprocesslistener, Itemwritelistener all the listening methods are executed in the chunk transaction, so if you want to handle the relationship between the business transaction and the chunk transaction in these listening methods, it is best to set the business transaction as the independent Require_new feature and avoid the mutual influence     About Onxxerror monitoring method: Change the Listener method to execute before the transaction rollback, or before the transaction commits (if there is a no-rollback-exception configuration)    A little suggestion      When using spring batch, you need to be aware of the problem domain it is addressing, and its own concern should be to provide a batch processing capability, that is, the bulk reading of files or databases, the conversion of write and protocol data, and the control of the entire process.      Therefore, if you need to do some business logic in the bulk processing process, then the implementation of the business logic needs to be independent of each other and try not to decouple the business logic during batch processing, for the following reasons:    A, Spring The purpose of batch is to be clearer     B, to avoid the occasional complexity of the cross-coupling of the spring batch transaction to the business logic transaction, the application is understood     second, SpriNG Batch system tables are best and business data tables are in the same physical library, ensuring transactional consistency   This article transfers from: 44154501

Spring Batch Transaction