Transaction timeout on step level vs server.xml

Question

On JSR-352 batch, I'm defining a transaction timeout in step level for chunk processing as 900s. At the same time I have transaction timeout mentioned in server.xml as 1800s. this chunk processing step is partitioned using PartitionMapper step. My question is when the step gets executed, few threads getting timed out using step level transaction timeout which is 900s. But few threads hanging for while and getting timed out based on server.xml transaction timeout which is 1800s.

<step id="ReportBatch" >
    <properties >
        <property name="javax.transaction.global.timeout" value="900"/>
    </properties></step>

server.xml
<transaction clientInactivityTimeout="1800" propogatedOrBMTTranLifetimeTimeout="1800" totalTranLifetimeTimeout="1800" transactionLogDirectory="${server.config.dir}/tranlog/"/>

I'm expecting thread should fail with 900s timeout mentioned in step level. Which transaction timeout takes the preference ? Is this fine to remove transaction time out from server.xml, or reduce the timeout limit on server.xml

Answer 1

Configuring transaction timeout

Yes, the step property javax.transaction.global.timeout" sets the transaction timeout for the partition-level threads executing "chunks" within a partitioned chunk step just as you had in the job XML (JSL) snippet:

<step id="ReportBatch" >
    <properties >
        <property name="javax.transaction.global.timeout" value="900"/>
    </properties>
    <chunk>...</chunk>
    <partition>...</partition>
</step>

The server configuration can set an upper bound for these "application" transaction timeouts via:

<transaction propogatedOrBMTTranLifetimeTimeout="1800s"/>

So with the above example, the effective tran timeout for your chunk transactions would be 900s.

This is detailed, along with a few other options in this question and answer.

What happens in a transaction timeout

When a transaction times out, the transaction is immediately marked for rollback, and a message appears in the messages.log along with details of the relevant thread, including a stack trace.

However, your application might not notice right away. If it is "hung" making a call over the network or doing a CPU-intensive calculation, it will continue on, and may only see an exception thrown when it touches a transactional resource, or checks the status of the transaction, etc.