locked
How to implement persistency in Beta 2 RRS feed

  • Question

  • Hello!

    In order to impement persistency for my workflows I've read:
    *) "A Developer's Introduction to Windows Workflow Foundation (WF4) in .NET 4 Beta 1".
    *) The WF4 sample "Persistence".

    It seems like there's no overlap between these two description. Can't you cast some light on this issue of persistency, how should it be achieved. If it's actually described somewhere you should obviously just refer to that.

    Specifically concerning "A Developer's Introduction to Windows Workflow Foundation (WF4) in .NET 4 Beta 1": The code in figure 26 "wf.OnIdle = () => IdleAction.Persist;" does not compile using Beta 2. Has this changed since Beta 1?



    Best regards,

    Henrik Dahl
    Tuesday, November 10, 2009 8:00 AM

Answers

  • Persistence has completely changed from beta 1 to beta 2.

    The key properties to look for on the WorkflowApplication are:
    • InstanceStore
    • PersistableIdle
    The InstanceStore needs to point to some form of InstanceStore. Out of the box you get the SqlWorkflowInstanceStore that stores its data in SQL Server

    The PersistableIdle is an function that returns a PersistableIdleAction (What the OnIdle did before).

    I am not aware of any good writeups showing how to do this. One of these days I will do so but for now all you have is a few samples in the WF/WCF .NET 4 samples kit.
    Tuesday, November 10, 2009 10:17 AM

All replies

  • Persistence has completely changed from beta 1 to beta 2.

    The key properties to look for on the WorkflowApplication are:
    • InstanceStore
    • PersistableIdle
    The InstanceStore needs to point to some form of InstanceStore. Out of the box you get the SqlWorkflowInstanceStore that stores its data in SQL Server

    The PersistableIdle is an function that returns a PersistableIdleAction (What the OnIdle did before).

    I am not aware of any good writeups showing how to do this. One of these days I will do so but for now all you have is a few samples in the WF/WCF .NET 4 samples kit.
    Tuesday, November 10, 2009 10:17 AM
  • Maurice,

    Thank you very much.

    Which source are you actually using for obtaining this information as I haven't seen it announced where I'm used to look?


    Best regards,

    Henrik Dahl
    Tuesday, November 10, 2009 12:51 PM
  • Mostly a lot of time in Reflector and the samples mentioned here.

    Maurice
    Tuesday, November 10, 2009 2:39 PM
  • Maurice,

    OK, it sounds a bit fundamentalistic or hard core!

    Do you know if an instance of SqlWorkflowInstanceStore may be referenced by multiple WorkflowApplication instances at the same time or one SqlWorkflowInstanceStore should be instantiated per WorkflowApplication?

    Do you know precisely what is going on here (which is code from the Persist sample):

     

     

    InstanceView view = instanceStore.Execute(instanceStore.CreateInstanceHandle(), new CreateWorkflowOwnerCommand(), TimeSpan.FromSeconds(30));

    instanceStore.DefaultInstanceOwner = view.InstanceOwner;

    To me it looks like in order to obtain valid semantics you must remember to do this in order to obtain valid calibration of the mutual locking stuff when multiple requests for a given workflow could show up from different directions at the same time.

    Do you know if it's sufficient with these two sql files for defining the foundation:
    *) SqlWorkflowInstanceStoreSchema.
    *) SqlWorkflowInstanceStoreLogic.

    Best regards,

    Henrik Dahl

    Tuesday, November 10, 2009 3:53 PM
  • Yes it is. However with the lack of documentation, not really surprising given a completely new stack, and the lack of blogging from the team, no comments there, it is pretty much all you can do if you want to know what is going on.

    As far as I know it is perfectly safe to use the same SqlWorkflowInstanceStore for multiple WorkflowApplication instances. The SqlWorkflowInstanceStore doesn't seem to hold any state with regard to the WorkflowApplication, only for SQL Server.

    The two SQL script should be all you need to run the SqlWorkflowInstanceStore. There are also scripts there for the 3.5 stack, which is still there and supported, but completely separate.

    I haven't really looked into the InstanceView  and CreateWorkflowOwnerCommand yet but my take is you need these when you are going to have a possibility of multiple SqlWorkflowInstanceStore objects work with the same worklfow.

    Tuesday, November 10, 2009 4:41 PM
  • Maurice,

    Yes, this describes the phenomena at the abstraction level it takes place at as I perceive it as well.

    Now I've tried it and after creating less than 200 workflows having the instance store associated I receive a System.InvalidOperationException exception holding this message:

    System.InvalidOperationException was unhandled
      Message=An incorrect implementation of the IAsyncResult interface may be returning incorrect values from the CompletedSynchronously property or calling the AsyncCallback more than once. The type System.Data.Common.DbAsyncResult could be the incorrect implementation.
      Source=System.Runtime
      StackTrace:
           at System.Runtime.AsyncResult.AsyncCompletionWrapperCallback(IAsyncResult result)
           at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
           at System.Data.Common.DbAsyncResult.ExecuteCallback(Object asyncResult)
           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
           at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
           at System.Threading.ThreadPoolWorkQueue.Dispatch()
           at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
      InnerException:

    Perhaps the persistence feature is simply not really complete as it's been introduced for Beta 2.

    Does it work to you for real, if you've tried it?


    Best regards,

    Henrik Dahl
    Tuesday, November 10, 2009 8:54 PM
  • Sounds to me like the persistence stuff might change again. Which is why the are sitting on any major effort to provide guidance.
    Wednesday, November 11, 2009 4:39 AM