From b7731c9336e5a3e2bf6f24d0312be56fd165c0bb Mon Sep 17 00:00:00 2001 From: lucasward Date: Tue, 1 Jul 2008 03:56:57 +0000 Subject: [PATCH] BATCH-691:Cleaned up chapter 4. Corrected the modifications made around transaction configuration in the repository and step implementations. Also added a small section about the SystemCommandTasklet. --- docs/src/site/docbook/reference/execution.xml | 112 ++++++++++++------ 1 file changed, 75 insertions(+), 37 deletions(-) diff --git a/docs/src/site/docbook/reference/execution.xml b/docs/src/site/docbook/reference/execution.xml index 2604bedc7..73a178267 100644 --- a/docs/src/site/docbook/reference/execution.xml +++ b/docs/src/site/docbook/reference/execution.xml @@ -499,16 +499,13 @@
Transaction Configuration For the JobRepository - If the JDBC daos are used with the JobRepository it is also - essential to configure the transactional behaviour of the + If either of the JobRepository factory beans are used, + transactional advice will be automatically created around the repository. This is to ensure that the batch meta data, including state that is necessary for restarts after a failure, is persisted correctly. The behaviour of the framework is not well defined if the - repository methods are not transactional. If you use the - JobRepositoryFactoryBean then the transaction - manager will be set up for you (this was not the case with Spring - Batch version 1.0.x). The isolation level in the - create* method attiributes is specified separately to + repository methods are not transactional. The isolation level in the + create* method attributes is specified separately to ensure that when jobs are launched there if two processes are trying to launch the same job at the same time, only one will succeed. The default isolation level for that method is SERIALIZABLE, which is @@ -517,23 +514,35 @@ collide in this way. However, since a call to the create* method is quite short, it is unlikely that the SERIALIZED will cause problems, as long as the database - platform supports it. + platform supports it. However, this can be overriden in the factory + beans: - To use the map DAOs you should add transaction boundaries - declaratively to the repository. Here is the relevant - configuration: + <bean id="jobRepository" + class="org.springframework.batch.execution.repository.JobRepositoryFactoryBean" + <property name="databaseType" value="hsql" /> + <property name="dataSource" ref="dataSource" /> + <property name="transactionManager" ref="transactionManager" /> + <property name="IsolationLevelForCreate" value="ISOLATION_REPEATABLE_READ" /> + </bean> - <aop:config> - <aop:advisor - pointcut="execution(* org.springframework.batch.core..*Repository+.*(..))" - <advice-ref="txAdvice" /> -</aop:config> + If the factory beans aren't used then it is also essential to + configure the transactional behaviour of the repository using + AOP: -<tx:advice id="txAdvice" transaction-manager="transactionManager"> - <tx:attributes> - <tx:method name="*" /> - </tx:attributes> -</tx:advice> + + <aop:config> + <aop:advisor + pointcut="execution(* org.springframework.batch.core..*Repository+.*(..))" + <advice-ref="txAdvice" /> + </aop:config> + + <tx:advice id="txAdvice" transaction-manager="transactionManager"> + <tx:attributes> + <tx:method name="*" /> + </tx:attributes> + </tx:advice> + + This fragment can be used as is, with almost no changes. Remember also to include the appropiate namespace declarations and @@ -586,9 +595,9 @@ - BATCH_STEP_EXECUTION_CONTEXT + BATCH_EXECUTION_CONTEXT - STEP_EXECUTION_ID = ? and KEY_NAME = ? + EXECUTION_ID = ? and KEY_NAME = ? On commit interval, a.k.a. chunk @@ -620,11 +629,11 @@ SimpleJob The only current implementation of the Job - interface is SimpleJob. Since a Job is just a - simple loop through a list of Steps, this implementation should be - sufficient for the majority of needs. It has only three required - dependencies: a name, JobRepository, and a list - of Steps. + interface is SimpleJob. Since a + Job is just a simple loop through a list of + Steps, this implementation should be sufficient for the majority of + needs. It has only three required dependencies: a name, + JobRepository, and a list of Steps. <bean id="footballJob" class="org.springframework.batch.core.job.SimpleJob"> @@ -654,8 +663,9 @@ role="bold">It is entirely up to the developer to ensure that a new instance is always created in this scenario. However, Spring Batch does provide some help. If a Job should never be - restarted, but should always be run as part of a new JobInstance, then - the restartable property may be set to 'false': + restarted, but should always be run as part of a new + JobInstance, then the restartable property may + be set to 'false': <bean id="footballJob" class="org.springframework.batch.core.job.SimpleJob"> @@ -1142,9 +1152,9 @@ <property name="retryableExceptionClasses" value="org.springframework.dao.DeadlockLoserDataAccessException" /> </bean> - The StatefulRetryStepFactoryBean requires a limit for the number - of times an individual item can be retried, and a list of Exceptions - that are 'retryable'. + The StatefulRetryStepFactoryBean requires + a limit for the number of times an individual item can be retried, and + a list of Exceptions that are 'retryable'.
@@ -1158,20 +1168,27 @@ there are many scenarios in which exceptions thrown from the ItemWriter should not cause a rollback because no action has taken place to invalidate the transaction. For this - reason, the SkipLimitStepFactoryBean can be configured with a list of - exceptions that should not cause rollback: + reason, the SkipLimitStepFactoryBean can be + configured with a list of exceptions that should not cause + rollback: <bean id="step2" class="org.springframework.batch.core.step.item.SkipLimitStepFactoryBean"> <property name="commitInterval" value="2" /> <property name="skipLimit" value="1" /> - <property name="noRollbackForExceptionClasses" - value="org.springframework.batch.item.validator.ValidationException" /> + <!-- No rollback for exceptions that are marked with "+" in the tx attributes --> + <property name="transactionAttribute" + value="+org.springframework.batch.item.validator.ValidationException" /> <property name="itemReader" ref="tradeSqlItemReader" /> <property name="itemWriter" ref="itemTrackingWriter" /> </bean> + + The TransactionAttribute property above + can be used to control multiple other settings such as isolation and + propagation behaviour. More information on setting transaction + attributes can be found in the spring core documentation.
@@ -1461,6 +1478,27 @@ <constructor-arg value="target/test-outputs/test-dir" /> </bean>
+ +
+ Executing System Commands + + Many batch jobs may require that an external command be called + from within the batch job. Such a process could be kicked off + separately by the scheduler, but the advantage of common meta-data + about the run would be lost. Furthermore, a multi-step job would also + need to be split up into multiple jobs as well. Because the need is so + common, Spring Batch provides a Tasklet + implementation for calling system commands: + + + <bean class="org.springframework.batch.sample.tasklet.SystemCommandTasklet"> + <property name="command" value="echo hello" /> + <!-- 5 second timeout for the command to complete --> + <property name="timeout" value="5000" /> + </bean> + + +