Transactions and schedulers
Transactions and the scheduler daemon
Scheduled BeanTaskInfo and MessageTaskInfo tasks execute 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:
- The context of the application that created the task is applied to the thread.
- A global transactional context is started.
- The next fire time and start-by time are calculated using the UserCalendar bean or the DefaultUserCalendar.
- 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.
- If the NotificationSink bean is set, a FIRING notification is fired.
- The BeanTaskInfo or MessageTaskInfo object has started.
- If the task fails and the NotificationSink bean is set, a FIRE_FAILED notification is fired on a separate transaction.
- If the task's NotificationSink bean is set, then the various notifications are fired as required.
- The global transaction is committed.
Because all events belonging to a task are executed in a single global transactional context, consider the following points in order to avoid transaction-related errors:
- Each resource participating in the task's transaction must be two-phase XA capable.
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 "Requires".
- One resource can be single-phase, if last participant support is enabled for the application that created the transaction. Enable last participant support using an assembly tool.
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 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, the transaction is rolled back, and the exception is resubmitted to the caller.
Related Tasks
Submitting a task to a scheduler