Transaction behavior when running a task
The scheduler runs a task in a single global transaction by default. This means that the transaction is open until the task completes or fails. The resources involved in that transaction are subject to various timeouts and the thread of the task could be identified as hung if the task runs for a long period of time that can span many minutes or hours.
The TaskInfo.setQOS
method allows reducing the quality of service for the task to run at-least-once.
When you set the task to TaskInfo.QOS_ATLEASTONCE, the task does not keep
a transaction open for the duration of the running task. Because this quality
of service is no longer transactional, the task may fire more than one time
if the scheduler fails to update the result of the task. This quality of
service is ideal for batch jobs. Use QOS_ATLEASTONCE with check points in
the business logic, so if the task needs to recover, the business logic can
continue at the next check point. See the com.ibm.websphere.scheduler.TaskInfo API documentation for
more details.
QOS_ONLYONCE
This includes the JDBC datasource configured for the scheduler, any JMS services used by the MessageTaskInfo objects, and any resources used within any of the UserCalendar, TaskHandler, or NotificationSink beans that have a transaction setting of "Required".
All unexpected exceptions are logged to the activity log and all events participating in the task's global transaction are rolled back. This includes changes to the task's database record, which force the task to be executed again when the scheduler daemon polls the database during the next poll cycle. The UserCalendar, TaskHandler, and NotificationSink beans can choose not to participate in the global transaction by configuring the bean transaction setting to "Requires new".
QOS_ATLEASTONCE
If a failure happens after the RUNNING state is written to the database and before the result is written, then the task may run more than one time.
When using QOS_ATLEASTONCE, all NotificationSink, UserCalendar and TaskHandler beans must not mandate a transaction (TX_MANDATORY), since there is no global transaction available when the task runs. The EJB components use "Required" or "Requires new" container managed transaction or a bean managed transaction.
Transaction behavior when using the Scheduler API methods or WASScheduler MBean operations
All Scheduler interface methods participate in a single global transactional context. If a global transactional context is already present on the thread when the create(), suspend(), resume(), cancel(), and purge() methods are executed, then the existing global transaction is used. Otherwise, a new global transaction begins.
If the method participates in the global transaction of the caller and an unexpected error occurs, then the transaction is marked to roll back. If the exception is a declared exception, then the exception is resubmitted to the caller, and the transaction is left alone for the caller to commit or roll back.
If the method starts its own global transaction and any exception occurs, then the transaction is rolled back, and the exception is resubmitted to the caller.
Related tasks
Submitting a task to a scheduler