Event for leaving the Idle state

Event for leaving the Idle state

• legoman26

  Riley,

  In Beta2, you will be able to use the method 'TryUnload' on the WorkflowInstance to implement the delayed-persistence scenario.  In the timed callback that you set up in WorkflowIdled, you can call TryUnload instead of Unload.  TryUnload will unload the instance only if it is idle, otherwise it will return false.  By doing so you'll be able to ensure that you're unloading the instance only if it is still idle after N seconds.   I just thought I'd update the thread so that when Beta2 is released, you can complete the implementation...hope it helps!

  Arjun

  
  

• JohnsonInBeijing

  Arjun,
  
  First, excuse me, but to have an OnActive event seems not to be a "good suggestion" but a requirement.  Without it, doing manual persistence in our case becomes fraught with problems it seems to me.  And our case seems to be not a corner one.
  
  As to your solution, I don't get it.  Say I start a timer OnIdle.   Before it expires, the wf goes active again.  The timer epires.  How does it now know that it should *not* unload the workflow   Can one query the state of the wf in a reliable way
  Riley
  

• jsin

  Riley,
  
  Unfortunately there is currently no runtime event generated for when the workflow begins executing again.  You could perhaps use a tracking service to get the notification, although it wouldn't be too elegant of a solution.  Another semi-solution would be to create a timer, in the Idle handler, that unloads the instance after N seconds.  If the workflow begins executing, the timed unload will only occur after the instance idles again.
  
  This is an excellent suggestion though, I've logged it and we'll certainly consider it for a future relase.  Thanks Riley!
  
  Arjun
  

• cell-gfx

  Riley,
  
  I agree with you, and be assured that we are tracking and following up on this issue appropriately.  I think the feedback we have gotten from all of you has been fantastic, and it's points like this that help us make WF as great as possible. 
  
  In regards to my solution, I labeled it as a semi-solution, because of the scenario you described.  Say the workflow goes idle, and in OnIdle, you start a timer whose callback unloads the workflow.  But, say the workflow begins executing again before the timer expires.  The workflow will continue executing, and the timer's callback will be called.  The callback will issue an Unload, and the workflow will complete any remaining work in its execution queue, before calling Unload.  So, after the 'second' batch of work completes, the workflow will be forced to unload, hence, only a semisolution.  As I mentioned, to only issue the unload if the workflow is not executing, a tracking service would be needed to capture the instance events for the workflow.  This isn't as elegant as responding to a runtime event, but I think it should work. 
  
  In response to your second question, workflow state can be queried by introspection of the TrackingRecords delivered over the tracking channel.  In Beta2 there will also be programmatic ways of querying instance state against the SQL tracking store.
  
  Arjun
  

• RogerAu

  Thanks Arjun for the update.  I believe this will work for us, although the ActiveEvent would be a cleaner solution.

  Looking forward to B2.  When is the projected date now

  Riley

  
  
• Event for leaving the Idle state