Transactions and the scheduler service

Transactions and the scheduler daemon

Scheduled BeanTaskInfo and MessageTaskInfo objects are guaranteed to execute only once. This is accomplished by grouping all of the work done in the task as a single unit of work. When each task fires, the following events occur in a single global transactional context:

  1. The context of the application that created the task is applied to the thread.
  2. A global transactional context is started.
  3. The next fire time and start-by time are calculated using the UserCalendar bean or the DefaultUserCalendar.
  4. The task database task record is updated in the database with the state of the next task or deleted if the task is complete and the task's auto-purge setting is true.
  5. The BeanTaskInfo or MessageTaskInfo object is executed.
  6. If the task fails and the NotificationSink bean is set, a FIRE_FAILED notification is fired on a separate transaction.
  7. If the task's NotificationSink bean is set, then the various notifications are fired as required.
  8. The global transaction is committed.

Because all of a task's events are executed in a single global transactional context, you need to consider the following points in order to avoid transaction-related errors:

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 setting the bean's transaction setting to "Requires new".

Transactions and the scheduler interface

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, the existing global transaction is used. Otherwise, a new global transaction begins.

If the method participates in the caller's global transaction and an unexpected error occurs, the transaction is marked to roll back. If the exception is a declared exception, then the exception is rethrown 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, the transaction is rolled back, and the exception is rethrown to the caller.




Searchable topic ID:   csch_tasktransaction
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/scheduler/concepts/csch_tasktransaction.html

Library | Support | Terms of Use | Feedback