Do not use parallel execution within plug-ins and workflow activities
Category: Design, Performance, Security, Supportability
Impact potential: High
Symptoms
Multi-threading or parallel calls within plug-ins or custom workflow activities can cause corruption of those the connections. As an example, executing parallel threads can log exceptions such as:
Generic SQL error.
The transaction active in this session has been committed or aborted by another session.
Also, non-thread safe objects such as items in the System.Collections Namespace can become corrupted by parallel threads.
Guidance
The sandbox service has been designed to execute calls in a specific order as part of a transaction. Developing plug-ins or custom workflow activities to make parallel or multi-threaded calls is not supported. Develop your plug-ins and custom workflow activities knowing that the calls will be performed sequentially and may need to be rolled back.
Note
Using parallel execution from a client program is a supported practice to optimize performance as needed. This guidance is specific to code written to be executed within a plug-in or custom workflow activity.
Problematic patterns
Plug-ins and custom workflow activities run within a single transaction and multiple threads introduced by parallel execution can corrupt the transaction. The following are examples of patterns and practices that should not be used within plug-ins and custom workflow activities:
- Using Task-based asynchronous pattern (TAP)
- Using Task Parallel Library (TPL)
- Using Managed Threading
Additional information
Using and updating shared pipeline context objects could cause these objects to contain unexpected results or become corrupted. The affect of this would be a failure in the plug-in or custom workflow activity.
See also
Parallel Processing, Concurrency, and Async Programming in .NET