locked
WF Services RRS feed

  • Question

  • I read the Godinho article in the January MSDN Magazine.  Rafael states that "it's important to notice that persistence is not allowed between the Receive and SendReplyToReceive Pair."  Therefore there is a "no-persist zone" there. 

    Where do you persist then when using WF Services?  I have read elsewhere that WF ASP.NET Service workflows are one of the "persist-able" types.  Is it not true that these workflows start with the Receive and end with the SendReplyToRecieve pair?  How are these persist-able then?

    By the way, in my copy of VS 4.0 it is the Receive and SendResponse pair.

    • Edited by Jerry Lanp Monday, January 10, 2011 10:01 PM Additional Thought
    Monday, January 10, 2011 12:32 AM

Answers

  • The Receive / SendReply pair are intended to support a request/response messaging pattern.  If the workflow persisted after the receive then the caller will have a timeout when your workflow persists.

    I'm not 100% sure but I believe that when there is a correlated SendReply that the runtime sets up a no-persist zone to prevent this from occuring.

    Workflows may persist on idle but if and only if the idle occurs when you are not in a no-persist zone.  Typically this would occur after the initial receive/send reply when your workflow encounters some other activity that causes idle (perhaps another receive/send reply)

    If I had more time at the moment I'd write a test just to be sure about this but I think I'm right.


    Sr. Program Manager, AppFabric Development Platform (WF/WCF) http://blogs.msdn.com/rjacobs http://www.twitter.com/ronljacobs
    • Marked as answer by Jerry Lanp Friday, January 28, 2011 12:09 AM
    Thursday, January 27, 2011 10:56 PM
  • Hi, Jerry

    ->"Rafael states that "it's important to notice that persistence is not allowed between the Receive and SendReplyToReceive Pair."  "

    That is not the truth. you can persist workflow between the Receive and SendResponse activity. you can try it yourself. 
            Receive
                |
             Delay
                |
         SendResponse

    Delay activity will induce workflow idel and workflow will be persistd if you have setup persistence store for this workflow service.

    ->"Where do you persist then when using WF Services?  "
    Usually, you have many Receive activities in one workflow. Receive activity can induce idle and then workflow will be persisted. while the same time, WCF host will listen user's request. when a user call the Receive operation. workflow will resume from persistence store and keep running to its next idle point(Receive, Delay,...)

    Hope this helps
    Regards


    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    • Marked as answer by Andrew_Zhu Monday, January 17, 2011 8:32 AM
    Wednesday, January 12, 2011 6:09 AM

All replies

  • The workflows persist after the Send activity completes execution. The workflow may wait for next receive activity and hence becomes idle. It is then unloaded from memory and persisted in database.

    The workflow cannot persist between the Receive and SendReplyToReceive Pair as it has to yet send the reply back to the client. Once it sends back the reply, it can persist.

    Regards,

    Neha

    Tuesday, January 11, 2011 6:16 AM
  • Hi, Jerry

    ->"Rafael states that "it's important to notice that persistence is not allowed between the Receive and SendReplyToReceive Pair."  "

    That is not the truth. you can persist workflow between the Receive and SendResponse activity. you can try it yourself. 
            Receive
                |
             Delay
                |
         SendResponse

    Delay activity will induce workflow idel and workflow will be persistd if you have setup persistence store for this workflow service.

    ->"Where do you persist then when using WF Services?  "
    Usually, you have many Receive activities in one workflow. Receive activity can induce idle and then workflow will be persisted. while the same time, WCF host will listen user's request. when a user call the Receive operation. workflow will resume from persistence store and keep running to its next idle point(Receive, Delay,...)

    Hope this helps
    Regards


    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    • Marked as answer by Andrew_Zhu Monday, January 17, 2011 8:32 AM
    Wednesday, January 12, 2011 6:09 AM
  • Hi Andrew,

    In which situations can applications benefit from NoPersistZone.

    Regards,

    Neha

    Wednesday, January 12, 2011 11:52 AM
  • Hi, Neha

    ->"In which situations can applications benefit from NoPersistZone."
    Any situations you don't want the workflow instance be persisted. for example. when a workflow instance enters into a transaction session. You want the workflow instance stay in the memory until all actions are done.

    Regards
    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    Monday, January 17, 2011 8:31 AM
  • Andrew,

    I'm still confused.

    The statement quoted above made by Rafael in in MSDN Magazine January 2011 Page 25, one third of the way from the bottom on the left column.

    I have also receive personal emails from Rafael restating the concept.  It would seem that NehaGupta also feels that the workflow cannont persist between the Receive and SendReplyToReceive Pair

    So here is my main issue.  I need to place the whole workflow in a loop which will run until told to stop, persisting itself on delay.  If I have a WF WCF Service running it begins with a Receive and  ends with a SendReply, so how would it ever persist?

    • Edited by Jerry Lanp Wednesday, January 26, 2011 1:34 PM Correction
    Wednesday, January 26, 2011 1:24 PM
  • The Receive / SendReply pair are intended to support a request/response messaging pattern.  If the workflow persisted after the receive then the caller will have a timeout when your workflow persists.

    I'm not 100% sure but I believe that when there is a correlated SendReply that the runtime sets up a no-persist zone to prevent this from occuring.

    Workflows may persist on idle but if and only if the idle occurs when you are not in a no-persist zone.  Typically this would occur after the initial receive/send reply when your workflow encounters some other activity that causes idle (perhaps another receive/send reply)

    If I had more time at the moment I'd write a test just to be sure about this but I think I'm right.


    Sr. Program Manager, AppFabric Development Platform (WF/WCF) http://blogs.msdn.com/rjacobs http://www.twitter.com/ronljacobs
    • Marked as answer by Jerry Lanp Friday, January 28, 2011 12:09 AM
    Thursday, January 27, 2011 10:56 PM
  • Hi Jerry,

    I have just replied the e-mail you sent me and found the MSDN document I used as a reference on my MSDN Magazine article. The document is called "Troubleshooting Correlation" (http://msdn.microsoft.com/en-us/library/ee358742.aspx), where you can find:

    “Persistence is not permitted between a Receive/SendReply pair or a Send/ReceiveReply pair. A no-persist zone is created that lasts until both activities have completed. If an activity, such as a delay activity, is in this no-persist zone and causes the workflow to become idle, the workflow will not persist even if it the host is configured to persist workflows when they become idle. If an activity, such as a persist activity, attempts to explicitly persist in the no-persist zone, a fatal exception is thrown, the workflow aborts, and a FaultException is returned to the caller. The fatal exception message is "System.InvalidOperationException: Persist activities cannot be contained within no persistence blocks.". This exception is not returned to the caller but can be observed if tracking is enabled. The message for the FaultException returned to the caller is "The operation could not be performed because WorkflowInstance '5836145b-7da2-49d0-a052-a49162adeab6' has completed".”

    RG - http://blogs.msdn.com/rafaelgodinho

    • Proposed as answer by Rafael.Godinho Monday, January 31, 2011 4:52 PM
    Monday, January 31, 2011 4:49 PM