春季批，XA和本地交易

Question

It is possible to have a jobRepository in spring batch to use local transactions but execute particular job steps in distributed XA transaction?

For XA I use Atomicos 3.8.0. Step is supposed to read the JMS message and update the DB after processing.

The relevant part of spring configuration:

<job id="job" xmlns="http://www.springframework.org/schema/batch">
     <step id="inventorySync">
         <tasklet transaction-manager="xaTransactionManager">
            <chunk reader="jmsQueueReader"
                   processor="messageProcessor"
                   writer="dbWriter"
                   reader-transactional-queue="true"/>
         </tasklet>
     </step>
</job> 

    <bean id="xaTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"
          lazy-init="true" depends-on="inventoryDataSource">
        <constructor-arg name="transactionManager" ref="userTransactionManager"/>
        <constructor-arg name="userTransaction" ref="userTransaction"/>
        <property name="allowCustomIsolationLevels" value="true"/>
    </bean>

<bean id="jobRepository" class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean">
    <property name="dataSource" ref="batchJobsDataSource"/>
    <property name="transactionManager" ref="transactionManager"/>
    <property name="databaseType" value="${batch.data.source.type}"/>
</bean>

    <jdbc:embedded-database id="batchJobsDataSource" type="HSQL"/>

    <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="batchJobsDataSource"/>
    </bean>

Answer 1

I have used an XA transaction across all 3 of those resources before successfully using Bitronix in unit testing and WebSphere JTA in production. If you have a separate transaction manager for the Batch Database from the rest of your step, you risk the step and batch database being 'out-of-sync' in the event of a failure in either one of the places (batch database or step).

for example, you may have a successful commit on your step (JMS and DB) and then failure on your batch Database. when you restart your job it will think that a certain step was unsuccessful whilst your underlying execution was. covering all 3 of the resources in the same transaction manager will prevent this.