Job Repository and Metadata - Spring Batch - page 99

parameters, which is a must-have in development. You might also run a job using the in-memory
repository for performance reasons. There is a cost to maintaining job state in a database that may not
be needed. Say, for instance, that you're using Spring Batch to do a data migration, moving data from
one database table to another; the destination table is empty to start, and you have a small amount of
data to migrate. In a case like this, the overhead of setting up a Spring Batch schema and using it may
not make sense. Situations that don't need Spring Batch to manage restarts and so on can use the in-
memory option.
The JobRepository you've been using so far is configured in the launch-context.xml file. In the
previous examples, you've configured the job repository using MySQL. To configure your job to use an
in-memory repository, you use the
org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean , as shown in
Listing 5-1. Notice that a transaction manager is still required. This is because the data the JobRepository
stores is still dependent on transaction semantics (rollback, and so on), and business logic may depend
on transactional stores as well. The transaction manager configured in the listing,
org.springframework.batch.support.transaction.ResourcelessTransactionManager , actually doesn't do
anything with transactions; it's a dummy transaction manager that provides a dummy transaction.
Listing 5-1. Configuring an In-Memory Job Repository
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns=" http://www.springframework.org/schema/batch"
xmlns:beans=" http://www.springframework.org/schema/beans"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=" http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/batch
http://www.springframework.org/schema/batch/spring-batch-2.1.xsd">
<beans:bean id="transactionManager"
class="org.springframework.batch.support.transaction.
ResourcelessTransactionManager"/>
<beans:bean id="jobRepository"
class="org.springframework.batch.core.repository.support.
MapJobRepositoryFactoryBean" p:transactionManager-ref="transactionManager" />
...
If you take the HelloWorld example from Chapter 2 and configure it to use the in-memory elements
of Listing 5-1, you see that you can run the job over and over without Spring Batch throwing an
exception for running the same job with the same parameters multiple times.
You should keep in mind a couple of limitations when using an in-memory job repository. First, as
already stated, because the storage of data is in memory, once a JVM is restarted the data is lost. Second,
because synchronization occurs in the memory space of a particular JVM, there is no guarantee that a
given job won't be executed with the same given parameters by executing the same job in two JVMs.
Finally, if your job is using any of the multithreading options (multithreaded step, parallel flows, and so
on) provided by Spring Batch, this option won't work.
That's it for the in-memory option. By making a small configuration tweak, you can prevent yourself
from having to deal with setting up a database to run your batch jobs. However, given the limitations of
this approach and the features that a persistent job repository provides, most of the time you'll use a
database to back your job repository. With that in mind, let's look at configuring the job repository in a
database.