Change Preprocessors versus Event Handlers
Knowing whether to use a change preprocessor or an event action handler is not always obvious, especially if you want to modify the source object.
The following table compares features of change preprocessors, which always run synchronously, with features of event action handlers, which you can configure to run either synchronously or asynchronously.
Change Preprocessor - synchronous | Event Action - synchronous | Event Action - asynchronous | |
---|---|---|---|
When does the action handler run? (Any request to the Content Engine can trigger one or more of each of the server extension types.) | In transaction, before database updates occur. Runs first. | In transaction, after database updates occur. Runs second. | After the transaction commits. Runs third in a separate transaction. |
Runs before the source object is saved? | yes | yes | no |
Server disables security access checks during execution? | no | yes | yes |
Gap in time between when the client saves the source object and the handler runs? | no | no | yes |
Can update the source object? | yes | no | yes |
Can update SettableOnlyonCreate (SOOC) properties? | yes | no | no |
Can update other objects that are referenced by object-valued properties (OVPs)? | yes | yes | yes |
Can subscribe to events? | no | yes | yes |
Execution can be filtered by event and property values? | no 1 | yes | yes |
Unhandled exceptions roll back the user's transaction? | yes | yes | no |
1 Change preprocessors are started unconditionally. However, the source object that is passed to a change preprocessor action handler includes a properties collection and a set of pending actions, which allows the action handler to filter by event and property values.