To unload or not to unload. That is the question RRS feed

All replies

  • Hi there.
    There is not a direct correlation between going idle and persisting.
    If you have it set up to persist and you have implemented the PersistableIdle function to return PersistableIdleAction.Unload then it will unload.  But you don't have to unload it.


    AutoResetEvent sync = new AutoResetEvent(false);
    WorkflowApplication instance = new WorkflowApplication(new Workflow1());
    instance.OnUnhandledException = OnError;
    instance.Idle = (WorkflowApplicationIdleEventArgs e) =>
    instance.PersistableIdle = (WorkflowApplicationIdleEventArgs e) =>
            return PersistableIdleAction.None;
    instance.Completed = (WorkflowApplicationCompletedEventArgs e) =>
            Console.WriteLine("Workflow Completed");


    This will idle it, but not unload it.
    Hope that helps.

    MS Developer Support
    Thursday, November 12, 2009 12:33 AM
  • So do you know when it is acceptable to unload? I have a workflow that is telling me it is idle but the delay activity has not taken steps to handle unloading the workflow.

    Do i have to interrogate the state of each executing activty?
    Thursday, November 12, 2009 6:37 AM
  • In your particular case, you're probably looking for a durable delay (see the sample on that) if you want to unload the workflow instance.
    You have two idle events that will get triggered, Idle and PersistableIdle.  If your app is not able to persist then you'll only get the one Idle event.  If it is, you'll get both.  In the PersistableIdle event you have the option to unload the workflow instance.  If you have a way of persisting your instance and reloading it then go ahead and unload it.  The WF\Basic\Persistence\InstancePersistence sample has a good demo of that.  For an in memory delay, however, you don't want to unload it.

    MS Developer Support
    Friday, November 13, 2009 11:06 PM
  • " If your app is not able to persist then you'll only get the one Idle event." That cool but I want to know if its ok to persist AND unload.

    "For an in memory delay, however, you don't want to unload it." That's the crux. How do I know when to unload it with out having explicit knowledge of the activities that are currently running and their ability to support an unload?

    If the Delay activity is not creating a bookmark.

    Saturday, November 14, 2009 3:11 AM
  • Hello! I am having a similar problem. Basically I am able to make the Delay activity to persist my workflow, however also setting up the Workflow Management Service it is not resming the delay at all.

    MicSmi, did you find a solution?
    Thank you

    Tuesday, December 1, 2009 4:27 PM
  • This still doens't answer the question of "How do you know at the workflow Applicaiton level if it is OK to unload?"
    Tuesday, December 8, 2009 4:06 AM
  • Trying to read between the lines, it sounds like it is up to you to decide if you want to unload it or not - but when the PersistableIdle handler is called it's a pretty big clue:
    The clue is that you're being told the workflow is idle, and that it's persistable. This is as close as the runtime can get to telling you that it is 'OK' to unload - the workflow isn't occupied doing work, after all, so why not unload it? (If unloading is an advantage for you.)

    Tuesday, December 8, 2009 5:03 AM
  • right but if you don't have a durable timer service setup it is NOT ok to persist AND unload. The delay activity should know that there is no such service and go into No_Persist block.
    Wednesday, December 9, 2009 6:06 AM
  • So the question is:

    'I don't remember enabling any Durable Timer services. So why do I get this PersistableIdle event at all?'

    I think there's two parts of the answer:

    1) If a persistance provider is available, PersistableIdle is the default. To get Idle event instead of PersistableIdle event requires that there be some NoPersist zone 'blocking' persistance.

    2) As far as I can tell: DurableTimer is the default TimerExtension. This is what would make persistance the default.


    Thursday, December 10, 2009 9:28 PM