Rolling Back Transactions

These conditions cause the system to set the Transactional setting on a new event state row:

  • FireEventSp or FireApplicationEvent() detects an enclosing transaction.
  • FireEventSp, FireApplicationEvent(), PostEventSp, or PostEvent() receives a Transactional setting.

This event state setting signals the system administrator that when this event state is finished and not rolled back, everything happened that was expected to happen.

In a synchronous multi-event situation, to encode the proper information in the Rolled Back setting, an enclosing transaction that contains one or more FireEventSp or FireApplicationEvent() calls must:

  1. Once, before calling FireEventSp or FireApplicationEvent(), call EventBeginTransactionSp or EventBeginTransaction().
    This uses a separate transaction to clear a storage area to record the row pointers of the event state rows to be created and returns a transaction identifier to be passed to FireEventSp or FireApplicationEvent().
  2. Pass that transaction identifier to FireEventSp or FireApplicationEvent().
    In a separate transaction, this records the row pointer of the new event state row.
  3. Upon rolling back or committing the transaction, call EventEndTransactionSp or EventEndTransaction() and pass the transaction identifier and whether a commit or rollback is performed.
    This uses a separate transaction to set the Rolled Back setting on the stored event state rows (if rolling back), and clears the storage area.
If this is neglected, the system administrator cannot determine why database actions that appear to have finished successfully according to the status forms are not reflected in the database.

In asynchronous situations and when a failure is detected by the event system, the Rolled Back setting for the failing transactional event is set by the event system.