views:

78

answers:

1

We have some objects that have an associated workflow instance. The objects are identified with a GUID, which is also the GUID of the workflow instance associated with the object. We need to restart (see NOTE 3 for the meaning of 'restart') the workflow instance if the workflow definition changed (there is no state in the workflow itself and it is written to support restarting in this manner).

The restarting is performed by calling Terminate on the WorkflowInstance, then recreating the instance with the same GUID. The weird part is that this works every other attempt (odd attempts - the workflow is stopped, but for some reason doesn't restart, even attempt - the already terminated workflow is recreated and started successfully).

While I admit that using 'second hand' GUIDs is a sign of extraordinary cheapness (and something we plan to change), I'm wondering why this isn't working. Any ideas?

NOTES:

  1. The terminated workflow instance is passivated (waiting for a notification) at the time of the termination.

  2. The Terminate call successfully deletes the data persisted in the database for that instance.

  3. We're using 'restarting' with a meaning that's less common in the context of WF - not restarting a passivated instance, but force the workflow to start again from the beginning of its definition.

Thanks!

A: 

It appears that calling Terminate() finishes the workflow very brutally, without even calling Uninitialize() on the root activity (which does some required cleanup in our case).

Our workaround is to throw an exception in the workflow (when handling an 'item available' event, so the 'termination' can be triggered by enqueuing an object on a special queue) so the workflow dies AND Uninitialize() is called.

Miron Brezuleanu