Its very popular problem then you use complex solution with receivers and workflows(WF).
Symptoms are corrupted WF execution and bad ULS messages like that:
-----------------------------------------------------------------------------------------------------
09/04/2012 18:48:23.88 w3wp.exe (0x0CD0) 0x1940 Windows SharePoint Services Workflow Infrastructure 88xr Unexpected WinWF Internal Error, terminating workflow Id# 94139810-91fb-457a-9b12-d21a68989b91
Symptoms are corrupted WF execution and bad ULS messages like that:
-----------------------------------------------------------------------------------------------------
09/04/2012 18:48:23.88 w3wp.exe (0x0CD0) 0x1940 Windows SharePoint Services Workflow Infrastructure 88xr Unexpected WinWF Internal Error, terminating workflow Id# 94139810-91fb-457a-9b12-d21a68989b91
09/04/2012 18:48:23.88 w3wp.exe (0x0CD0) 0x1940 Windows SharePoint Services Workflow Infrastructure 98d4 Unexpected System.Workflow.Runtime.Hosting.PersistenceException: Save Conflict Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes. ---> Microsoft.SharePoint.SPException: Save Conflict Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes. ---> System.Runtime.InteropServices.COMException (0x81020037): Save Conflict Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes.
-----------------------------------------------------------------------------------------------------
To use WFs and especially with some concurrency code like receivers, you must strongly understand how WFF works.
My case on this problem:
-----------------------------------------------------------------------------------------------------
To use WFs and especially with some concurrency code like receivers, you must strongly understand how WFF works.
My case on this problem:
- webservice listen for incoming connection and close Nintex(Workflow) task
- after close i write some fields to WF item
While my async receiver(updated) on WF item updating, WFF reach the next commit point, in my case its state machine change.
Its funny, the problem was resolved after i swap two lines of code. Task close and WF item update.
You must update WF item first, cause task completion becomes WF active.
No comments:
Post a Comment