BATCH-503: Modify docos to show changes to TX configuration in factory beans.

This commit is contained in:
dsyer
2008-05-26 12:25:23 +00:00
parent 7025ff4831
commit 3cc0bf5fed

View File

@@ -13,13 +13,13 @@
<mediaobject>
<imageobject role="html">
<imagedata align="center"
fileref="images/spring-batch-reference-model.png"
fileref="images/spring-batch-reference-model.png"
width="75%" />
</imageobject>
<imageobject role="fo">
<imagedata align="center"
fileref="src/site/resources/reference/images/spring-batch-reference-model.png"
fileref="src/site/resources/reference/images/spring-batch-reference-model.png"
width="75%" />
</imageobject>
</mediaobject>
@@ -452,7 +452,8 @@
<programlisting> &lt;bean id="jobRepository"
class="org.springframework.batch.execution.repository.JobRepositoryFactoryBean"
&lt;property name="databaseType" value="hsql" /&gt;
&lt;property name="dataSource" value="dataSource" /&gt;
&lt;property name="dataSource" ref="dataSource" /&gt;
&lt;property name="transactionManager" ref="transactionManager" /&gt;
&lt;/bean&gt;</programlisting>
<para>The databaseType property indicates the type of incrementer that
@@ -497,11 +498,24 @@
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.</para>
repository methods are not transactional. If you use the
<classname>JobRepositoryFactoryBean</classname> 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
<code>create*</code> method attiributes 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
quite aggressive: READ_COMMITTED would work just as well;
READ_UNCOMMITTED would be fine if two processes are not likely to
collide in this way. However, since a call to the
<classname>create*</classname> method is quite short, it is unlikely
that the SERIALIZED will cause problems, as long as the database
platform supports it.</para>
<para>The Spring Batch samples have a
simple-job-launcher-context.xml configuration file that contains the
necessary details. Here is the relevant section:</para>
<para>To use the map DAOs you should add transaction boundaries
declaratively to the repository. Here is the relevant
configuration:</para>
<para><programlisting>&lt;aop:config&gt;
&lt;aop:advisor
@@ -511,25 +525,14 @@
&lt;tx:advice id="txAdvice" transaction-manager="transactionManager"&gt;
&lt;tx:attributes&gt;
&lt;tx:method name="create*" propagation="REQUIRES_NEW" isolation="SERIALIZABLE" /&gt;
&lt;tx:method name="*" /&gt;
&lt;/tx:attributes&gt;
&lt;/tx:advice&gt;</programlisting></para>
<para>This fragment can be used as is, with almost no changes. The
isolation level in the <code>create*</code> method attiributes is
specified 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. This is quite aggressive, and READ_COMMITTED would
work just as well; READ_UNCOMMITTED would be fine if two processes
are not likely to collide in this way. However, since a call to the
<classname>create*</classname> method is quite short, it is unlikely
that the SERIALIZED will cause problems, as long as the database
platform supports it.</para>
<para>Remember also to include the appropiate namespace declarations
and to make sure spring-tx and spring-aop (or the whole of spring)
is on the classpath.</para>
<para>This fragment can be used as is, with almost no changes.
Remember also to include the appropiate namespace declarations and
to make sure spring-tx and spring-aop (or the whole of spring) is on
the classpath.</para>
</section>
<section>
@@ -1636,4 +1639,4 @@
itself.</para>
</section>
</section>
</chapter>
</chapter>