locked
Stopping an activity within the branch of a parallel activity from relinquishing control of the workflow thread? RRS feed

  • Question

  • I have 5 activities that update a database table within a parallel activity.  When the database update occurs the workflow thread switches to another activity within the parallel.  I do not need a transaction on the database update because only one table is involved, but I absolutely cannot have the thread switch occur until after the activity that performed the update is complete.  Right now I am using a C# lock statement within each activity to ensure that my internal state will not be corrupted when the thread switch occurs but this is really not an ideal solution.  Will making each activities a child of a TransactionScopeActivity prevent the thread switch from occurring during the database update?

    bmukes

    Monday, October 6, 2014 4:09 PM

Answers

  • I commented out all of my lock statements and retested and the behavior no longer is appearing.  So I guess it was (EBKAC) error between keyboard and computer.  Thanks for your quick response and I'm sorry for having wasted your time.


    bmukes

    • Marked as answer by Angie Xu Monday, October 13, 2014 2:25 AM
    Tuesday, October 7, 2014 7:06 PM

All replies

  • I am assuming the SQL operations that the 5 activities are doing are performed in an asynchronous manner so that the executing activity goes idle while the SQL operation is outstanding, thus "releasing" the thread to move on to the next branch of the Parallel. This is how the Parallel activity is designed - it executes one branch until it becomes idle and then moves on to the next branch, and so forth, until all the branches have become idle, then the Parallel becomes idle, making the workflow instance idle and eligible for unload (if your host is appropriately configured).

    Is the concern that the thread switches from Activity (branch) 1 to Activity (branch) 2 when Activity 1 fires off its asynchronous SQL operation, and thus goes "idle" waiting for the async operation to complete? Or is the concern that the completion of the async SQL operation fired off by Activity 1 happens on a different thread than the thread that started the async operation?

    If the concern is the former issue, it sounds like you have a synchronization concern between your activities such that you don't want one to execute while another still has a SQL operation outstanding. If that's the case, should they really be part of a Parallel? Or should they be asynchronous operations allowing the activity to become idle while the SQL operation is outstanding?

    If the concern is the latter, again, do you really want the SQL operation done asynchronously. If the activity can't tolerate the operation being completed on a different thread, you should probably make the operation synchronous, thus retaining the thread for the duration of the operation.

    The TransactionScope activity will not make the Parallel "single threaded" in the way it sounds like you want. It will guarantee that all the activities will operate under the same transaction and will prevent the workflow instance from persisting until the transaction scope is complete. But if one of the branches in the Parallel goes idle waiting for an asynchronous operation, another branch of the Parallel will execute.

    Jim

    Tuesday, October 7, 2014 6:06 PM
  • I commented out all of my lock statements and retested and the behavior no longer is appearing.  So I guess it was (EBKAC) error between keyboard and computer.  Thanks for your quick response and I'm sorry for having wasted your time.


    bmukes

    • Marked as answer by Angie Xu Monday, October 13, 2014 2:25 AM
    Tuesday, October 7, 2014 7:06 PM
  • Hmm. I guess I don't understand the "bad" behavior you described. I was under the impression that the problem was that Activity 2 was executed before Activity 1 had finished its SQL operation. I don't understand how removing the locks helped here.

    Anyway, I am glad to hear things are working as expected now.

    Jim

    Tuesday, October 7, 2014 8:01 PM