Protecting Running Application Events from Metadata Changes

Once an event handler begins execution, you must prevent changes to its attributes and actions. Otherwise, unpredictable behavior results, especially if actions are resequenced.

One way to prevent these changes is to make a copy of all active, non-obsolete handlers and their actions each time an application event is triggered and control execution from this copy. However, that method results in the persistence of a great number of identical copies, assuming that handlers are modified much less frequently than they are executed.

Since the system stores state data separately from metadata, it makes a copy only when the metadata changes, and furthermore only when the corresponding application event is triggered and a copy of the last metadata modifications has not yet been made.

In other words, handler metadata for an application event can be created and edited as many times as necessary. The first time the application event is triggered, a copy of the last saved metadata is made. This copy is called an event revision. The execution of the event's handlers is then controlled by the event revision and not by the original metadata (which happen to be identical at this point).

The application event can be triggered as many times as necessary, all the time controlled by this event revision, as long as no intervening modifications have been made to the original metadata.

After one or more metadata edits have been saved, the next time the application event is triggered, the system copies a new event revision from the last-saved metadata.