locked
Why is there a NoPersistHandle inside a CorrelationHandle? RRS feed

  • Question

  • I've been trying to debug a workflow persistence problem and it took a while before I could even catch the exception that described the problem. Apparently I'm trying to persist inside a no-persist zone... but the Persist activity is inside my top-level flowchart. The only execution property in the scope is a CorrelationHandle, which, apparently, contains a private NoPersistHandle. 

    What controls the usage of this NoPersistHandle? I need the CorrelationHandle in the top-level scope since I'm using content-based correlation, but I also need to be able to persist the workflow since it's long-running.

    Friday, August 6, 2010 9:37 AM

Answers

  • Hi,

    Is the Persist activity between a Receive/SendReply? That is a no-persist zone. Otherwise I cannot think of any correlation related reason that a workflow could not persist. What was the exception? Did it specifically say that you were trying to persist in a no-persist zone?

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Zhen Lin Friday, August 6, 2010 3:09 PM
    Friday, August 6, 2010 3:04 PM

All replies

  • Hi,

    Is the Persist activity between a Receive/SendReply? That is a no-persist zone. Otherwise I cannot think of any correlation related reason that a workflow could not persist. What was the exception? Did it specifically say that you were trying to persist in a no-persist zone?

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Zhen Lin Friday, August 6, 2010 3:09 PM
    Friday, August 6, 2010 3:04 PM
  • Yes, at one stage during the debugging I did have the Persist activity in between a Receive and a SendReply, and I got the persist in a no-persist block exception then. I continued to get that exception even after I moved the Persist activity to an outer scope, but now I think that was because the workflow engine was executing the old workflow definition.

    I also had persistence problems when I did not use any explicit Persist activities - now that you mention that Receive/SendReply forms a no-persist zone, I'm wondering if my problems were because my workflow only becomes idle inside a Receive activity? I now have an explicit Persist before my Receive activities, and everything seems to work.

    Friday, August 6, 2010 3:09 PM