Rolling back transactions

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

  • 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 FireApplicationEvent() calls must perform these actions:

  1. Once, before calling 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 FireApplicationEvent().
  2. Pass that transaction identifier to 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 Application Event System (AES), the Rolled Back setting for the failing transactional event is set by the AES.