Recovery mode property

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.

Important:
For some interfaces it is important that events be processed in the order in which they are received. If event sequencing is not important to the integrity of an interface then you can implement deferred recovery without regard to the order in which failed or new flows are processed. If event sequencing is important, however, and you need to implement deferred recovery then you must document and follow administrative procedures to ensure that event sequencing is maintained. For instance, the administrator must make sure that the collaboration does not receive and process new flows when the system is restarted before the failed flows are resolved. This can be done by managing the startup or polling of the source connector agents that would send new events to the collaboration in question.

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 ]

Copyright IBM Corp. 1997, 2003