(Edit 2016-12-02: Reworked with an explanation of the defaulting behavior when a timeout value of '0' is set for the application transaction).
Let me describe the application-level options and how that interacts with the server-level timeout.
In a chunk step in WebSphere Liberty Java Batch, you can either set an application-level timeout, or set a timeout value of '0' to default to a server-level timeout.
In addition, you can also set an upper bound for any non-zero application-level timeout value through a separate server-level setting.
The chunk transaction timeout can be set either:
At the step level in JSL with special step property: javax.transaction.global.timeout (seconds)
E.g.
<step id="MyStep">
<properties>
<!-- In seconds -->
<property name="javax.transaction.global.timeout" value="120"/>
If not explicitly defined in XML, it defaults to 180 (seconds).
If you need more dynamic/programmatic control you can implement a custom CheckpointAlgorithm and write its checkpointTimeout() to return whatever you want (a different value for each chunk even if you really wanted).
You can prevent the application from setting too great a timeout value.
In the server config (server.xml) use propogatedOrBMTTranLifetimeTimeout :
<transaction propogatedOrBMTTranLifetimeTimeout="90s"/>
This will act as an upper bound on any non-zero application timeout value, either via javax.transaction.global.timeout
or your checkpointTimeout() method,
In the case that the javax.transaction.global.timeout
is set to '0' or the case that your checkpointTimeout() method returns '0', you will get a default timeout from the server.
This timeout value defaults to 120 seconds.
To change in the server config (server.xml) use totalTranLifetimeTimeout, e.g.:
<transaction totalTranLifetimeTimeout="60s"/>
As mentioned above, though, if javax.transaction.global.timeout
isn't set at all the application timeout defaults to 180, and so the totalTranLifetimeTimeout does NOT come into play.
Note: the WDT tool's Design View makes working with and remembering these server config attribute values much easier.
The propogatedOrBMTTranLifetimeTimeout attribute here basically maps to the Maximum transaction timeout in traditional, while the totalTranLifetimeTimeout maps more obviously the Total transaction lifetime timeout in traditional.
Some nice examples are described within this documentation which are still largely relevant in Liberty.