In previous releases, if a fatal system error occurred then all flows being processed at the time of failure would be recovered when the system was restarted. The flows were all read from persistent storage and resubmitted for processing. If there were many such flows, the system memory could actually be consumed entirely by the act of retrieving the events into memory, possibly resulting in another fatal system error related to lack of sufficient memory. Furthermore, you could not effectively manage the system with the tools until InterChange Server Express had completed its recovery processing.
As of release 4.0.0 it is possible to defer recovery for a collaboration object by setting the Recovery mode drop-down menu to the value Deferred. If you configure a collaboration object for deferred recovery in this manner, any flows that are in progress at the time of a fatal system error are treated as failed flows and are not recovered immediately when the system is restarted. Then, prior to recovery, the administrator can use Flow Manager to resubmit the flows after the system has restarted and the desired administrative actions have been taken.
Deferred recovery is less critical due to optimized recovery measures introduced in release 4.2.0. Rather than reading into memory the entire business object data for in-progress transactions, the server only reads enough information in memory to locate the business object in persistent storage. Although deferred recovery is still available, you may not require it because of this new optimized recovery approach.
See also
[ Top of Page | Previous Page | Next Page | Table of Contents ]