You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/scalable-customization-design/database-transactions.md
+21-25Lines changed: 21 additions & 25 deletions
Original file line number
Diff line number
Diff line change
@@ -1,21 +1,16 @@
1
1
---
2
-
title: "Scalable Customization Design: Database Transactions (Microsoft Dataverse) | Microsoft Docs"# Intent and product brand in a unique string of 43-59 chars including spaces
3
-
description: "The second in a series of topics. This topic focuses on the impact of database transactions on scalable customization design"# 115-145 characters including spaces. This abstract displays in the search result.
4
-
ms.custom: ""
5
-
ms.date: 1/15/2019
6
-
ms.reviewer: "pehecke"
7
-
8
-
ms.topic: "article"
9
-
author: "rogergilchrist"# GitHub ID
10
-
ms.author: "jdaly"# MSFT alias of Microsoft employees only
> This is the second in a series of topics about scalable customization design. To start at the beginning, see [Scalable Customization Design in Microsoft Dataverse](overview.md).
21
16
@@ -31,20 +26,21 @@ One of the most fundamental concepts behind many of the challenges faced here is
31
26
A common reason that problems can occur in this area is the lack of awareness of how customizations can affect transactions.
32
27
33
28
Although the details of how this is done is beyond the scope of this topic, the most simple element to consider is that as Dataverse interacts with data in its database. SQL Server determines the appropriate locks to be taken by transactions on that data such as:
29
+
34
30
- When creating a record, it generates a write lock against that record.
35
31
- When updating a record, it takes a write lock against the record.
36
-
- When a lock is taken against a table or record, it’s also taken against any corresponding index records.
32
+
- When a lock is taken against a table or record, it's also taken against any corresponding index records.
37
33
38
-
However, it’s possible to influence the scope and duration of these locks. It’s also possible to indicate to SQL Server that no lock is required for certain scenarios.
34
+
However, it's possible to influence the scope and duration of these locks. It's also possible to indicate to SQL Server that no lock is required for certain scenarios.
39
35
40
-
Let’s consider SQL Server database locking and the impact of separate requests trying to access the same data. In the following example, creating an account has set up a series of processes, some with plug-ins that are triggered as soon as the record is created, and some in a related asynchronous workflow that is initiated at creation.
36
+
Let's consider SQL Server database locking and the impact of separate requests trying to access the same data. In the following example, creating an account has set up a series of processes, some with plug-ins that are triggered as soon as the record is created, and some in a related asynchronous workflow that is initiated at creation.
41
37
42
38
The example shows the consequences when an account update process has complex post processing while other activity also interacts with the same account record. If an asynchronous workflow is processed while the account update transaction is still in progress, this workflow could be blocked waiting to obtain an update lock to change the same account record, which is still locked.
43
39
44
40
45
41
46
42
It should be noted that transactions are only held within the lifetime of a particular request to the platform.
47
-
Locks aren’t held at a user session level or while information is being shown in the user interface. As soon as the platform has completed the request, it releases the database connection, the related transaction, and any locks it has taken.
43
+
Locks aren't held at a user session level or while information is being shown in the user interface. As soon as the platform has completed the request, it releases the database connection, the related transaction, and any locks it has taken.
48
44
49
45
50
46
## Blocking
@@ -59,7 +55,7 @@ While the first request to grab the auto-number resource lock can easily be comp
59
55
60
56
## Lock release
61
57
62
-
There are two primary reasons why a lock isn’t released but is held until the transaction is completed:
58
+
There are two primary reasons why a lock isn't released but is held until the transaction is completed:
63
59
64
60
- The database server holds onto the lock for consistency in case the transaction will later make another request to update the data item.
65
61
- The database server also has to allow for the fact that an error or abort command issued later can cause it to roll the entire transaction back, so it needs to hold onto the locks for the entire lifetime of the transaction to ensure consistency.
@@ -93,9 +89,9 @@ Before understanding how customizations interact with the platform, it is useful
93
89
94
90
|Operation|Description|
95
91
|--|--|
96
-
|Forms (Retrieve)|•More likely to have conflicts. An update lock will block anything else updating that record.|
92
+
|Forms (Retrieve)|•Low impact on other uses.|
97
93
|Create|• Performs a create request through the platform<br />• Low impact on other activities, as a new record nothing else blocking on it<br />• Can potentially block locking queries to the whole table until it is complete.<br />• Often can trigger related actions in customization which can have an impact.|
98
-
|Update|• Performs an update request through the platform.<br />• More likely to have conflicts. An update lock will block anything else updating or reading that record. Also blocks anything taking a broad read lock on that table.<br />• Often triggers other activities.<br />• In some rare cases, an update lock can block a read lock. One example of where this can occur is when Dataverse metadata is being changed: Reads done by a Dataverse metadata change transaction will be blocked by update locks.|
94
+
|Update|• Performs an update request through the platform.<br />• More likely to have conflicts. An update lock will block anything else updating that record.<br />• Often triggers other activities.<br />• In some rare cases, an update lock can block a read lock. One example of where this can occur is when Dataverse metadata is being changed: Reads done by a Dataverse metadata change transaction will be blocked by update locks.|
99
95
|View (RetrieveMultiple)|• Would think this would block lots of other activity.<br />• Although poor query optimization can affect DB resource usage and possibly hit timeouts.|
100
96
101
97
## Event pipeline: platform step
@@ -106,7 +102,7 @@ When an event pipeline is initiated, a SQL transaction is created to include the
106
102
107
103
## Customization requests
108
104
109
-
It’s also possible to participate in the platform initiated transaction within customizations. Each type of customization participates in transactions in a different way. The following sections will describe each in turn.
105
+
It's also possible to participate in the platform initiated transaction within customizations. Each type of customization participates in transactions in a different way. The following sections will describe each in turn.
110
106
111
107
-[Sync plug-ins (pre or post operation: in transaction context)](#sync-plug-ins-pre-or-post-operation-in-transaction-context)
112
108
-[Sync plug-ins (pre and post operation: in transaction context)](#sync-plug-ins-pre-and-post-operation-in-transaction-context)
@@ -141,15 +137,15 @@ A plug-in can also be registered to act outside of the platform transaction by b
This scenario only applies when the **PreValidation** is called as the first stage of a pipeline event . Even though the plug-in is registered on the **PreValidation** stage, it is possible it will participate in a transaction as the next section describes. It can’t be assumed that a **PreValidation** plug-in doesn’t participate in a transaction, although it is possible to check from the execution context if this is the case.
140
+
This scenario only applies when the **PreValidation** is called as the first stage of a pipeline event . Even though the plug-in is registered on the **PreValidation** stage, it is possible it will participate in a transaction as the next section describes. It can't be assumed that a **PreValidation** plug-in doesn't participate in a transaction, although it is possible to check from the execution context if this is the case.
145
141
146
142
### Sync plug-ins (**PreValidation**: in transaction context)
147
143
148
144
The related scenario occurs when a **PreValidation** plug-in is registered but the related pipeline event is triggered by message request from within an existing transaction.
149
145
150
146
As the following diagram shows, creating an account can cause a **PreValidation** plug-in to perform initially outside of a transaction when the initial create is performed. If, as part of the post plug-in, a message request is made to create a related child account because that second event pipeline is initiated from within the parent pipeline, it will participate in the same transaction.
151
147
152
-
In that case, the **PreValidation** plug-in will discover that a transaction already exists and so will participate in that transaction even though it’s registered on the **PreValidation** stage.
148
+
In that case, the **PreValidation** plug-in will discover that a transaction already exists and so will participate in that transaction even though it's registered on the **PreValidation** stage.
153
149
154
150
155
151
@@ -160,7 +156,7 @@ As previously mentioned, the plug-in can check the execution context for the <xr
160
156
A plug-in can also be registered to act asynchronously. In this case, the plug-in also acts outside of the platform transaction.
161
157
162
158
> [!NOTE]
163
-
> The plug-in doesn’t create its own transaction; each message request within the plug-in is acted upon independently.
159
+
> The plug-in doesn't create its own transaction; each message request within the plug-in is acted upon independently.
164
160
165
161
166
162
@@ -171,7 +167,7 @@ To summarize:
171
167
172
168
- Synchronous plug-ins typically participate in transactions.
173
169
- Async plug-ins never participate in a platform transaction; each request is performed independently.
174
-
-**PreValidation** plug-ins don’t create a transaction but participate if one already exists.
170
+
-**PreValidation** plug-ins don't create a transaction but participate if one already exists.
175
171
176
172
|Event|Stage name|Transaction does not yet exist|Transaction already exists|
177
173
|--|--|--|--|
@@ -216,7 +212,7 @@ Custom actions can create their own transactions. This is a key feature. A custo
216
212
- If called through a message request from a plug-in running within the transaction, and Enable Rollback is set, the custom action will act within the existing transaction.
217
213
- The custom action will otherwise create a new transaction and run within that.
218
214
- Enable Rollback not set
219
-
- The custom action won’t act within a transaction.
215
+
- The custom action won't act within a transaction.
0 commit comments