|HomeShow ChangesEditPrintRecent ChangesSubscriptionsLost and FoundFind ReferencesRename
The WF runtime doesn't load all idle instances on startup, that would be crazy.
The WF persistence service has two flags that governs how it loads. One is the locked flag which is set when a WF runtime has a workflow instance loaded in memory. This prevents other WF runtimes potentially running on other servers from loading the same instance at the same time. The locked flag has a timeout associated with it just incase the WF runtime that has locked a WF instance and that timeout is set in the persistence service constructor. The second flag is the blocked flag which is set when the WF instance is waiting for a message or waiting on a delay timeout. When this flag is set it means that the WF instance is idle. When the persistence service starts up it only loads WF instances that are not locked and also not blocked. This subset represents all the WF instances that are ready to run and need the CPU to execute on right away. In the case where you have an existing web farm there is an existing WF runtime that is loading WF instances into RAM and executing them as messages arrive and timeouts occur. If you add a new WF runtime node to such a farm the only WF instances loaded on startup would be ones that have very recently experienced a timeout. This is very unlikely to represent the thousands of instances loaded in an overload condition.
This wiki site is supposed to be a shared resource. As a shared resource everyone is encouraged to add new content or modify existing content!
Enjoy the WF wiki.
Click to read this topic
23-11-2009 15:31:34 - anonymous