Do not use parallel execution within plug-ins and workflow activities
Effective November 2020:
- Common Data Service has been renamed to Microsoft Dataverse. Learn more
- Some terminology in Microsoft Dataverse has been updated. For example, entity is now table and field is now column. Learn more
This article will be updated soon to reflect the latest terminology.
Category: Design, Performance, Security, Supportability
Impact potential: High
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.
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.
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.
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
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.