IBM E02HMLL-I Implementation Guide - Page 31

However, collaborations are different from traditional transactions in some important ways: v Collaboration actions are distributed, and there is no centralized control over the participating databases. v Collaborations that respond to events (as in the publish-and-subscribe model) are long-lived; they execute asynchronously, because to isolate application data while they execute would adversely affect application users. v Applications save data changes caused by collaborations, thereby providing a distributed, cross-application form of durability. However, if a collaboration needs to roll back, it might need to undo previously saved operations. The techniques that the InterChange Server Express uses to support transactional collaborations, therefore, differ from those that support traditional transactions. The transaction levels associated with collaborations define the rigor with which the InterChange Server Express enforces transactional semantics. Recovery features An InterChange Server Express implementation provides features for improving the time it takes ICS to reboot after a failure, for making ICS available for other work before all flows have been recovered, and for controlling the resubmission of failed events: v Asynchronous recovery InterChange Server Express does not wait for collaborations and connectors to recover before it completes boot-up; collaborations and connectors are allowed to recover asynchronously after InterChange Server Express has booted. This makes it possible to use System Manager troubleshooting tools, such as System Monitor, while the connectors and collaborations are still recovering. v Deferred recovery Use of this feature is optional and is configured through the use of collaboration object properties. If you enable this feature for a collaboration, when an ICS failure occurs, the recovery of the collaboration's WIP flows is deferred until after the server has rebooted, thereby saving the memory usage associated with those flows. After the server has rebooted, you can resubmit the events. v Persist service call in-transit state You may want to prevent a recovery from automatically resubmitting all service calls that were in transit when a failure occurred, to avoid the possibility of a nontransactional collaboration sending duplicate events to a destination application. This is accomplished by configuring the collaboration (prior to the server failure) so that it will persist any service call event in the In-Transit state when a failure and recovery occurs. When InterChange Server Express recovers, the flows that were processing service calls remain in the In-Transit state, and you can examine individual unresolved flows and control when (or if) they are resubmitted. v Guaranteed event delivery features For JMS-enabled connectors (connectors that use JMS as their transport mechanism), the following features can be useful for guaranteed event delivery in recovery situations: - Container managed events The container managed events feature is valid for JMS-enabled connectors that use a JMS event store. It ensures that if a system crash and recovery occurs, an event that was in process between the event store and the connector framework will be received exactly once by the connector Chapter 1. Overview of IBM WebSphere Business Integration Server Express 19