locked
Pick-Activity and Resuming of Bookmarks RRS feed

  • General discussion

  • Hi all,

    I figured out a behavior in Pick activity, which at least to me seems to be very strange. Because I’m not sure is that bug or feature, it would be interesting to see some more or less official statement.

    Assume there is a workflow with Pick activity. The Pick Activity has two branches: P1 and P2. Each branch has as trigger the custom activity which registers on bookmark. For example triggers in B1 and B2 register bookmarks B1 and B2 respectively.

    Last but not least, the Pick activity is a child of loop implemented by While-activity. The reason for this is very simple. Pick wait for events in the loop. After tone event is fired the loop will activate Pick again etc.

    The  host will fire an event by invoking of

     wfInstance.ResumeBookmark(“B1”) or wfInstance.ResumeBookmark(“B2”).

    As long one of bookmarks is resumed all works fine.
    But when I invoke both bookmarks

    wfInstance.ResumeBookmark(“B1”);
    wfInstance.ResumeBookmark(“B2”);

    the second one will fail with following exception: BookmarkNotFoundException.

    It seems that WF runtime disposes triggers in all PickBranch-es after the first PickBranch has received an event. Assuming that my statement is the right one, I would expect different behavior in this case.
    Theoretically I agree that this behavior is the right one, because Pick will by definition always execute one branch, so all other triggers nobody needs.

    However practically, I will mostly have number of simultaneously fired events which all have one destination: Pick. In my opinion these event have to be queued.

    Currently, Pick is designed to observe one event at time. The only question is what the allowed time between events is? If the time between successively fired events to the Pick is shorter than Pick-execution time, the sender of event will fail.

    This means that the producer of events will have to take a care about Pick internals. I he doesn’t’ take a care his events will be lost. Both is bad.

    Damir

    Saturday, June 20, 2009 11:10 PM

All replies

  • The pick is the replacement for the Listen activity in WF3.  One thing to keep in mind is that the pick does clean up all triggers, but should only do so after the first trigger activity has completed.  So, if your trigger activity takes some time to complete, then you are more likely to get the second bookmark to resume.  Which branch executes depends on which trigger activity completes first, not which one gets the data first.  This is my understanding of how it should work, but I'm not sure how closely the beta holds to this.  

    matt


    Check out Pluralsight On Demand! http://www.pluralsight.com/main/olt/
    Monday, June 22, 2009 1:29 PM
  • Hi Matt

    the trigger activity does not take any time to complete. It just registers the bookmark and returns.
    Monday, June 22, 2009 1:46 PM
  • Then it's not complete.  :)  Registering the bookmark means the activity is technically still executing (i.e. not closed) so the trigger is not fired.  Once you resume the bookmark, then the activity could close if you don't do something to keep it open.  And, once the trigger activity is closed, then the Pick will cancel the other triggers and schedule the action for the trigger that completed. 

    Matt

    Check out Pluralsight On Demand! http://www.pluralsight.com/main/olt/
    Monday, June 22, 2009 2:40 PM
  • Ohh, just misunderstanding Matt J

    My intention was more like: “the trigger EXECUTE METHOD does not take any time to complete”.

    But, back to your statement “ One thing to keep in mind is that the pick does clean up all triggers, but should only do so after the first trigger activity has completed

    This is exactly the behavior I could approve. But if so by design, shouldn’t be slightly changed?
    In my opinion this could be a design issue because:

    Currently, Pick is designed to observe one event at time. The only question is what the allowed time between events is? If the time between successively fired events to the Pick is shorter than Pick-execution time, the sender of event will fail.

    This means that the producer of events will have to take a care about Pick internals. If he doesn’t his events will be lost.

    How do you see this Matt? To make it more simple, imagine you have a loop in the host which receive messages and dispatch them to the Workflow with Pick activity by invoking of ResumeBookmark. If the loop is enough fast, almost every event will fail.

     

    Monday, June 22, 2009 4:16 PM
  • In the MSDN description of the Pick Activity they write "At execution time, the triggers for all branches are executed in parallel. When one trigger completes, then its corresponding action is executed, and all other triggers are canceled."

    So theoretically there is no allowed "time between events". The first trigger to finish cancels the other triggers so the only delay is the activity within the trigger and therefore the marginal time taken to call the webservice method or access the workflow instance.

    If one had longer running operations you would have to implement some kind of lock mechanism (save a wf_locked = 1 value in the database) and then queue events in your client application accessing the workflow to be completely safe.

    Thursday, February 9, 2012 9:34 AM