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>
+
+
+