Performance considerations

To ensure optimum performance when designing FSMs:

• Avoid too many state changes. A design that breaks a process into a number of very small steps, with related states, might be aesthetically appealing. However, keep in mind that each state change involves updates to the database.
• Use the Render as message property carefully. Setting this property to the value false for events that are raised in the normal flow of a process can result in significant performance improvement. The consequence is that more activity can be included in a single unit of work, resulting in fewer commits. However, if an error occurs, more work will have to be rolled back.
• Use event filters where several transitions rely on the same event. Use an event filter to quickly exclude transitions that do not apply to a particular instance of an event (based on the value of context data, such as transaction type). This prevents your from issuing a database query that returns no objects.
• Use the override selector to be selective with the data columns that are retrieved for individual transitions. For example, the ISF_DATA column often returns a large amount of data, but might be required for only a small subset of possible actions. It is better to add an override selector to include all data columns of an object that will be required for an action, otherwise the action will need to make additional database queries to retrieve the required data.
• Design for event aggregation as much as possible.
• When defining events try to avoid defining many optional contexts that are rarely used. It may be better to define a second event type to cover the exceptional case.
• Avoid implementing many steps that require re-parsing the ISF data.
• Consider reducing the amount of audit information that is recorded. It is possible to turn off event logging for individual events. If a log of all events is not required, disable logging as appropriate.
• The default setting is to record all state changes for all objects. To modify this, change, or remove the corresponding trigger procedures.
• Remember that object selectors and object filters result in database queries. Consider database concurrency issues. Try to avoid selecting or locking records that are not needed by using well designed where clauses coupled with appropriate database indexes.