Batch_Job_Execution Status after runtime exception

Hi,

I am launching my jobs as such using JMS:

Code:

---

                try {
                        jobLauncher.run(jobLocator.getJob("myJob"), builder.toJobParameters());
                }
                catch (JobExecutionException e) {
                        log.error("Could not execute job.", e);
                }
                catch(RuntimeException e){
                        log.error("Exception.", e);
                }

---

I'm forcing a RuntimeException within the step, specifically a LineAggregator and I noticed the Status column of Batch_JOB_Execution stays at STARTING, shouldn't this job be marked by an error exit code in that table?

Is there an extra step I should take?

Thanks,
Angel

It should have a status of 'FAILED', but what's fishy to me is that the status is 'STARTING', if you started a job it should be 'STARTED'....STARTING is only there for a very short amount of time. Can you post your configuration? Also, what version of SB are you using?

It's definitely a transaction issue, I just removed the xa transaction manager from my spring jms listener-container and now status for jobs are marked as FAILED, the message listener transaction is not comitting and instead it's timing out which I don't understand why, it seems like spring batch is leaving it open when it encounters an exception, can anybody shed some light?

How do you have you transaction manager setup?

I use an XA data source

Code:

---

<tx:jta-transaction-manager id="transactionManager" />

<jms:listener-container connection-factory="jmsConnectionFactory"
                              transaction-manager="transactionManager"
                                destination-resolver="jndiJmsResolver"
                                message-converter="lockboxMessageConverter">
                        <jms:listener destination="jms/lockboxQueue" ref="lockboxMessageDelegate" method="recieve"/>
</jms:listener-container>

 <bean id="jobRepository"
          class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean">
            <property name="databaseType" value="oracle" />
            <property name="dataSource" ref="dataSource" />
            <property name="transactionManager" ref="transactionManager"/>
  </bean>

---

I'm launching the job within the MDB.

Quote:

---

Originally Posted by lucasward

It should have a status of 'FAILED', but what's fishy to me is that the status is 'STARTING', if you started a job it should be 'STARTED'....STARTING is only there for a very short amount of time. Can you post your configuration? Also, what version of SB are you using?

---

I'm using version 1.1.0

Switch off container-managed-transaction in your MDB? It looks like you are running the whole job in a single transaction.

Quote:

---

Originally Posted by Dave Syer

Switch off container-managed-transaction in your MDB? It looks like you are running the whole job in a single transaction.

---

I removed the transaction manager from the jms listener bean, and it started working as expected but then the JMS no longer participates in the transaction, is there any other way?

You want the whole job in a single transaction? It isn't usually a great idea - you'll tie up an expensive resource for the entire duration. The redo logs might get pretty scary, and rollback gets really expensive once you start doing a lot of stuff in a single transaction.

Spring Batch is designed so that if there is a failure you can trigger the job again (you can even trigger it again if you aren't sure - you'll get an exception saying the job is already executing). You can use that feature instead of relying on transactions in the message listener.

No, actually I was thinking of having the batch job work in a nested transaction, so the JMS message can survive an exception and be consumed again effectively restarting the job, for the job perse i would be comitting after each few writes, still your post kinda convinced me that handling the MDB in a transaction is a probably useless idea in practice, and an even worse idea if the batch job is of long duration (although thats not the case).