Note

If you have never developed or administered COM components, you might wonder why dehydration takes place after 180 seconds (three minutes). Well, a COM application is allowed to be idle for three minutes (default value) before it is shut down to save system resources.

Now comes the "but"—dehydration is not always possible! This is very important to understand and to act upon, since it is technically possible that long-running transactions that cannot be dehydrated will drain the resources of the system.The following are the exceptions where dehydration is not possible:

■ One or more short-lived (DTC-style) transactions are active.This is possible since a business process can have concurrent flows, which we discuss in the section "Flowchart, Communication, and Implementation Shapes."This is also true if a long-running transaction contains one or more DTC-style transactions.

■ A component that is bound to a port is nonpersistent. A component is persistent if it holds state and supports the IPersist interface that enables the XLANG schedule engine to retrieve the state of the component and save it in its database. If you are not a component developer, this might seem to be a trivial remark, but Microsoft's component development guidelines always discourage the use of stateful components because of the negative impact on performance and scalability.

■ The business process is not in a full wait state. As mentioned, if you have concurrent flows in your business process, they all need to be in the same "Wait for response" state for the scheduler engine to dehydrate.

The second and third exceptions are issues that you need to address during the development process.The first exception is in most cases a temporary runtime issue.

Keep in mind that when the long-running transaction fails, committed database changes are not automatically rolled back.This is only possible with DTC-style transactions. The On Failure of Transaction page should be used to compensate eventual database changes.This touches on a very important issue: if you change database rows that are used by other applications, or worse, also changed by other applications, you cannot restore the "old" values without bringing the database into an inconsistent status.

Was this article helpful?

0 0

Post a comment