On Wed, 2003-10-29 at 08:31, Dale Strickler wrote: > This is good *IF* it is not a critical system. If the application is > moving billions of financial transactions around the world and it costs > brokers millions of dollars for every minute of down time just "stop > everything, and let someone fix it" is not a good answer. The application > needs to identify the failure point, establish what is likely good or bad > data and charge ahead. (After leaving a solid trail of bread crumbs for > someone to follow....)
Pardon me while I faint. I'd say it's EXACTLY in critical systems that you should stop dead in your tracks (with, of course, the caveat that your tracks should be as small as possible) until someone corrects the problem. Yes, halting the flow of real money is a bad thing. Making real money flow when the data governing that flow is bad is, almost always, an even worse thing, since then, instead of delays, you have to correct the effects of real money going where it shouldn't have. Presumably, in a real application, only the transaction that prompted the failure would be terminated, and the rest of the system, and other transactions, would continue to function. But again, this is a responsibility for your application coders and more generally for your system architects. In general, I think we're all arguing for systems to have suitable failsafe modes. For example, consider an application whose job it was to admit oxygen, at a certain rate, into a sealed room, to maintain the respiration of its occupants. This system had *better* be designed that, in the event of a catastrophic failure--say, the processor running the application suddenly vaporizes itself--there is a default, nonzero oxygen flow into the room that's probably good enough, even if not most efficient or whatever, for most conditions. Adam
