[Edit; seems like VTS attributes are not picked up as I expected]
A not so uncommon error that people encounter with SharePoint workflow is running into locked tasks. You know, the error that you get when working with workflow tasks, usually on your developer machine. You might get the error message "This task is currently locked by a running workflow and cannot be edited.".
Why do I know it is not uncommon? Well, if you use my common-o-meter you'll see for yourself:
That is a lot of hits!
So many people have this issue with task locking. Generally it goes like this. A developer creates a workflow that issues a couple of tasks. Next the developer fiddles with his code to get it right. Then, returning to his test workflow, he finds that when editing a task and clicking Ok, the SharePoint UI informs him of the fact that the task is locked and cannot be edited.
So, what is going on here? There are a number of items that show up searches for this error message, but never a good explanation on why you got there in the first place. More symptom management that bug fixing! Well, the first thing to note is that the error is absolutely correct. The task is locked, but why is it locked, and was it not unlocked appropriately? Despite what many people think this has nothing to do with your DLL versions, at least not as directly as you might find written and guessed at. Here's the story.
How workflow tasks are locked
The first thing to realize is that when SharePoint workflows alter tasks there needs to be some sort of locking behavior on tasks so that you will not accidentally create race conditions and update a task simultaneously, the one update overwriting the other. Typically database level locks are used but for SharePoint Workflow tasks however a more simple, business-layer type lock suffices. Since SharePoint workflow is about humans and not about maximum near real-time performance the chance of collisions is low enough not to be worried about this. The workflow runtime in SharePoint locks tasks by setting a field and persisting that to the database. It then checks on the field value to determine whether it is locked. You can actually see the code that does this. The SPWinOEItemEventReceiver implements the ItemUpdating and ItemUpdated events. In the ItemUpdating you can find code similar to the following pseudo code
if WorkflowVersion for item not equal to 1
throw locked error
else
Place lock (Set WorkflowVersion on item to value not equal to 1)
How the lock placement is actually implemented is that the WorkflowVersion is set to the value in _UIVersion, which contains a value indicating the major / minor version of the task. Why _UIVersion? It ties the lock to a specific version of the list item, and versioning is enabled on workflow task lists. This probably allows the locks to be bypassed by other code inside SharePoint depending on the version. (By the way: do *not* use this knowledge of internals in production code)
The next interesting question is where the lock is released. The ItemUpdated event facilitates this. When the task lock is detected in the ItemUpdated event it is routed to the SPWorkflowManager. This manager runs code to dehydrate and startup the workflow (which was persisted to the database while waiting for the task change to occur). The SPWorkflowManager uses the SPWinOeHostServices workflow service to unlock the task in the PostWorkItemDequeue method and runs the workflow.
Running into the locking issue
So, the issue is that the lock is still there even though it should have been released in the ItemUpdated event. Clearly, the ItemUpdated event is where the issue lies, and like all bugs in life, you did it, and not the framework! (hope that does not come as a shocker to you) There is only one aspect of the locking that you can control, and that is the persistence and hydration of your workflow to and from the database. This is exactly what is causing the bugs. When the ItemUpdated event fires and tries to de-serialize your workflow there might be an exception during the hydration of your workflow object. This error is difficult to see since it is happening in non-user code based on an asynchronous event. When that error occurs, the task unlocking code does not run!
The general flow of events to create this issue goes something like this.
- Developer designs a workflow which creates a task.
- Developer tests the workflow, and runs it up to the task change activity, meaning that the workflow is now serialized in the database waiting for a task change to occur.
- Developer spots a bug, and updates the workflow in such a way that de-serialization breaks.
- Developer updates the task through the browser to continue the workflow .
- Runtime bumps into the de-serialization error, and cannot continue, hence the task unlocking code does not run, and the task is locked for all eternity.
A common de-serialization issue that you might create is a change in the activity structure, or the addition of control fields in your main workflow class.
Preventing the locking issue
Now that we have a clear understanding of the issue, there are many things you can about it. On development I'd go for re-running the entire workflow (at least when it is not too big).
On Production, it is even easier:
DO NOT UPGRADE UNTIL ALL RUNNING WORKFLOWS ARE COMPLETE
You should quiesce a workflow and when all running workflows have completed, update. Or, when you need to have the business logic available during the quiescing, you can only create a new workflow.
Hope it helps!
代码
Thank you so much for the tip, your code did the trick. I think the reason WorkflowVersion changes is because there's a different version of the workflow dll. So when you recompile your workflow and DLL is changed in the GAC while there are still running workflows, trying to finish any of those workflows might give you "This task is currently locked.." error.