Java Reference
In-Depth Information
Database
Using a Database Repository is the predominant way to configure a job repository. It allows you to
utilize all the benefits of a persistent store with little impact on your job's overall performance. Later, this
chapter looks at some hard numbers to illustrate the cost of using a database.
For now, however, let's start by looking at the MySQL configuration you've been using in the
examples. You can see the configuration in Listing 5-2. In this case, you begin with the datasource. This
example uses the
org.apache.commons.dbcp.BasicDataSource
provided by Apache Commons, but any
datasource you want to use is ok. Listing 5-2 sets the values of the various properties (driver class,
database URL, username, and password) via properties in the
batch.properties
file. This allows you to
configure those properties specific to the environment you're working in (your production environment
has different values than your test environment, which has different values than your local
development).
Listing 5-2.
Job Repository Configuration in
launch-context.xml
Using a Database
<beans:bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<beans:property name="driverClassName" value="${batch.jdbc.driver}" />
<beans:property name="url" value="${batch.jdbc.url}" />
<beans:property name="username" value="${batch.jdbc.user}" />
<beans:property name="password" value="${batch.jdbc.password}" />
</beans:bean>
<beans:bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
lazy-init="true">
<beans:property name="dataSource" ref="dataSource" />
</beans:bean>
<job-repository id="jobRepository" data-source="dataSource"
transaction-manager="transactionManager"/>
The next thing you configure is the transaction manager. Again, you keep it simple here by using the
basic
DataSourceTransactionManager
provided by Spring, but any transaction manager will do.
DataSourceTransactionManager
has a single dependency: an actual datasource that you've configured.
The last aspect of the transaction manager is that it's configured to be lazily initialized
1
which is optional
per the Spring documentation but because Spring Batch's shell project has it configured this way, there
is no reason to change it.
Finally you come to the job repository factory. The first thing to call out about this configuration is
that you don't use the regular
bean
tag. Instead, Spring Batch provides a tag specific for configuring the
job repository. In order to configure the job repository this way, you need to add references to the Spring
Batch XSD to
launch-context.xml
as you did in Listing 5-1, because it isn't included by default. With the
job-repository
tag, the only attribute that is required is
id
. By default, Spring autowires the
data-source
and
transaction-manager
attributes of
JobRepositoryFactoryBean
with beans named
dataSource
and
transactionManager
, respectively.
1
By default, Spring instantiates all singleton beans on startup. Because you don't know what will
happen, there is no reason to go through the work of creating a transaction manager if it won't be used.
