Analysis of the Problem
The basic issue here is that a thread which is processing a PO with (as an example) document id 12345 is also updating a different document with id 54321.
However, document 54321 is also being processed by a searchable attribute indexing thread. So an optimistic lock occurs. See the following diagram which illustrates the issue:Gliffy
There are a few possible solutions here:
- Require the code in KFS to clear the persistence broker cache before the second loading of the document
- Force the KFS code to manually lock all documents that will be modified during engine execution
- Add a new method to the PostProcessor
getDocumentIdsToLock(...). This should return the document IDs of all documents that are going to be modified during engine or post processor processing. The engine can that execute the locking on those document IDs as the first step.
- Set up some other way (in the data model) to link related documents together. Then the engine could automatically lock related documents prior to engine execution.
- Spawn another thread to make changes to document 54321 (in the above example).
Out of the above steps, it seems like 3 is the best option for addressing this.
We will need to:
- Determine which PostProcessing code in KFS makes changes to other workflow documents.
- Figure out if it's possible for those documents to implement such a method on their PostProcessor
- Implement the change in the KEW PostProcessor interface and StandardWorkflowEngine
- Implement the new PostProcessor method in the PostProcessor for the KFS documents that need it