Conception de personnalisation évolutive : transactions de base de données

Notes

Il s′agit de la deuxième d′une série de rubriques concernant la conception de personnalisation évolutive. Pour commencer dès le début, voir Conception de personnalisation évolutive dans Microsoft Dataverse.

L′un des concepts principaux derrière plusieurs des défis relevés ici est celui de la transaction de base de données. Dans Dataverse, la base de données est au cœur de presque toutes les demandes au système et la cohérence des données d′emplacement est appliquée en premier lieu.

• Aucune opération de données Dataverse, interne ou dans le cadre de personnalisations de code, ne fonctionne entièrement dans un contexte isolé.
• Toutes les opérations de données Dataverse interagissent avec les mêmes ressources de base de données, à un niveau de données ou à un niveau d′infrastructure tel que le processeur, la mémoire, ou l′utilisation d′E/S.
• Pour se protéger des modifications contradictoires, chaque demande met des verrous sur les ressources à afficher ou à modifier.
• Ces verrous sont placés dans une transaction et ne sont pas libérés tant que la transaction n′est pas validée ou abandonnée.

Connaissance des transactions et du verrouillage

L′une des raisons communes pour lesquelles des problèmes peuvent survenir dans cette zone est l′absence de connaissances sur la façon dont les personnalisations peuvent affecter des transactions.

Bien que les détails sur la façon dont cela est effectué soient hors de la portée de cet article, l′élément le plus simple à prendre en compte est la manière dont Dataverse interagit avec les données dans sa base de données. SQL Server détermine les verrous appropriés à placer par transaction sur ces données telle que :

• Lors de la création d′un enregistrement, il génère un verrou en écriture sur cet enregistrement.
• Lors de la mise à jour d′un enregistrement, il place un verrou en écriture sur l′enregistrement.
• Lorsqu′un verrou est placé sur une table ou un enregistrement, il est également placé sur tous les enregistrements d′index correspondants.

Toutefois, il est possible d′influencer l′étendue et la durée de ces verrous. Il est également possible d′indiquer à SQL Server qu′aucun verrou n′est requis pour certains scénarios.

Par exemple, dans le cas d′un verrouillage de base de données SQL Server et l′impact des demandes distinctes essayant d′accéder aux mêmes données. Dans l′exemple suivant, la création d′un compte a défini une série de processus, certains avec des plug-ins déclenchées dès que l′enregistrement est créé, et certains dans un workflow asynchrone qui est initié à la création.

L′exemple illustre les conséquences lorsqu′un processus de mise à jour de compte a un post-traitement complexe lorsque une autre activité interagit également avec le même enregistrement de compte. Si un workflow asynchrone est traité tandis que la transaction de mise à jour de compte est toujours en cours, ce workflow peut être bloqué en attendant d′obtenir un verrou de mise à jour pour modifier le même enregistrement de compte, qui est encore verrouillé.

Il convient de noter que les transactions sont uniquement conservées pendant la durée de vie d′une demande spécifique sur la plateforme. Les verrous ne sont pas conservés à un niveau de session utilisateur ou lorsque des informations sont affichées dans l′interface utilisateur. Dès que la plateforme a terminé la demande, elle libère la connexion de la base de données, la transaction associée, et tous les verrous qu′elle l′a placés.

Blocage

Bien que le type de blocage de l′exemple précédent peut être incommode seul, il peut également entraîner des conséquences plus graves lorsque vous estimez que Dataverse est une plateforme qui peut traiter des centaines d′actions simultanément. Bien que le maintenir d′un verrou sur un enregistrement de compte individuel peut avoir raisonnablement des implications limitées, que se passe-t-il lorsqu′une ressource est plus fortement contestée ?

Par exemple, lorsque chaque compte obtient un seul numéro de référence, cela peut aboutir au blocage d′une seule ressource effectuant le suivi des numéros de référence utilisés par chaque processus de création de compte. Comme décrit dans l′Exemple de numérotation automatique, si de nombreux comptes sont générés en parallèle, des demandes se chevauchant devront toutes accéder à cette ressource de numérotation automatique et la bloqueront jusqu′à ce qu′elles terminent leur action. Plus chaque processus de création de compte est long, plu sil existe de demandes concurrentes, et plus les blocages se produisent.

Bien que la première demande de saisie du verrou de ressource de numérotation automatique puisse être facilement exécutée, la seconde demande devra attendre que la première se termine avant de pouvoir contrôler quel est le prochain numéro de référence unique. La troisième demande devra attendre que la première et la deuxième demandes se terminent. Plus il y a de demandes, plus le blocage sera long. S′il y a suffisamment de demandes, et que chaque demande est suffisamment longue, cela peut repousser les demandes ultérieures au point qu′elles expirent, même si individuellement elles pourraient se terminer correctement.

Libération de verrou

Il existe deux raisons principales pour lesquelles un verrou n′est pas libéré mais est maintenu jusqu′à ce que la transaction soit terminée :

• Le serveur de base de données maintient le verrou à des fins de cohérence dans le cas où la transaction fait ultérieurement une autre demande pour mettre à jour l′élément de données.
• Le serveur de base de données doit également tenir compte du fait qu′une erreur ou une commande d′abandon émise ultérieurement peut entraîner l′annulation de toute la transaction, il doit par conséquent maintenir les verrous pour la durée de vie complète de la transaction pour garantir la cohérence.

Il est important de savoir que même si votre processus a peut-être réalisé des interactions avec un élément de données spécifique, un verrou sera conservé jusqu′à ce que la transaction soient entièrement terminée et validée. Plus la transaction est prolongée, plus le verrou sera verrou conservé, ce qui empêche d′autres threads d′interagir avec les données. Comme indiqué plus tard, cela comprend également des personnalisations associées qui s′effectuent dans la même transaction et peuvent prolonger de manière significative la durée de vie des transactions telles que les workflows synchrones.

Dans l′exemple suivant, le verrou en écriture sur une entité personnalisée dans le plug-in préalable à la création d′un compte est verrouillé jusqu′à ce que toute logique liée à la création du compte se termine.

Erreurs intermittentes : chronologie

Le comportement intermittent est un symptôme évident de blocage d′une activité simultanée. Si la répétition de la même action aboutit ultérieurement alors qu′elle avait précédemment échoué, il existe une très forte probabilité que l′erreur ou la lenteur ait été causée par un autre élément se produisant en même temps.

Il est important de comprendre que déboguer un problème implique souvent de réinitialiser la fonctionnalité concernée au strict minimum. Toutefois, si le problème se produit uniquement par intermittence, vous devrez peut-être rechercher où l′action en échec est en conflit avec une autre activité dans le système, et vous devrez rechercher de potentiels points de compétition. Vous pouvez atténuer le conflit en optimisant un processus individuel ; toutefois, plus le temps de traitement est court, moins l′activité sera en conflit avec d′autres processus.

Contrôle de transaction

Lorsque dans la plupart des cas la façon dont les transactions sont utilisées peut être simplement laissé à la gestion de la plateforme, il existe des scénarios où la logique requise est suffisamment complexe qu′il est nécessaire de comprendre et d′influencer les transactions pour obtenir les résultats souhaités. Dataverse offre plusieurs méthodes de personnalisation qui affectent différemment la manière dont les transactions sont utilisées.

Lorsque vous comprenez comment chaque type de personnalisation participe aux transactions de plateforme, vous pouvez modéliser des scénarios complexes efficacement dans Dataverse et prévoir leur comportement.

Comme mentionné plus haut, une transaction est seulement maintenue pendant la durée de vie d′une demande à la plateforme. Ce n′est pas une opération qui est maintenue une fois l′étape de plateforme terminée. Cette durée limitée évite que les transactions soient conservées par un client externe pendant de longues périodes et bloquent d′autres activités de plateforme.

La tâche de la plateforme consiste à maintenir la cohérence dans l′ensemble du pipeline de transactions de la plateforme et le cas échéant de permettre aux personnalisations de participer à la même transaction.

Comment les applications basées sur des modèles utilisent les transactions

Avant de comprendre comment les personnalisations interagissent avec la plateforme, il est utile de comprendre comment les applications basées sur des modèles utilisent les demandes à la plateforme, et quelles sont les répercussions sur l′utilisation des transactions.

Operation	Description
Formulaires (Retrieve)	• Impact réduit sur d′autres utilisations.
Create	• Effectue une demande de création via la plateforme • Impact réduit sur les autres activités, en tant que nouvel enregistrement que rien d′autre ne bloque. • Peut potentiellement bloquer les requêtes de verrou de toute la table jusqu′à ce qu′elle soit terminée. • Peut souvent déclencher des actions associées dans la personnalisation qui peuvent avoir un impact.
Update	• Effectue une demande de mise à jour via la plateforme. • Plus de risque d′avoir des conflits. Un verrou de mise à jour bloquera toute autre mise à jour de cet enregistrement. • Déclenche souvent d′autres activités. • Dans de rares cas, un verrou de mise à jour peut bloquer un verrou de lecture. Un exemple où cela peut se produire est lorsque les métadonnées Dataverse sont modifiées : les lectures effectuées par une transaction de modification des données Dataverse seront bloquées par des verrous de mise à jour.
Afficher (RetrieveMultiple)	• Impact réduit sur d′autres utilisations. • Les requêtes peu performantes peuvent surcharger les ressources de la base de données et atteindre des délais d’expiration.

Pipeline d′événements : étape de plateforme

Lorsqu′un pipeline d′événements est initialisé, une transaction SQL est créée pour inclure l′étape de plateforme. Cela garantit que toutes les activités de base de données effectuées par la plateforme sont traitées de manière cohérente. La transaction est créée au début du pipeline d′événements et validée ou abandonnée lorsque le traitement est terminé, selon que celui-ci a réussi.

Demandes de personnalisation

Il est également possible de participer à la transaction initiée par la plateforme dans les personnalisations. Chaque type de personnalisation participe aux transactions de manière différente. Les sections suivantes présentent ces options dans l′ordre.

• Plug-ins synchrones (avant ou après l′opération : dans le contexte de transaction)
• Plug-ins synchrones (avant et après l′opération : dans le contexte de transaction)
• Plug-ins synchrones (Validation préalable : hors du contexte de transaction)
• Plug-ins synchrones (Validation préalable : dans le contexte de transaction)
• Plug-ins asynchrones
• Résumé d′utilisation de transaction de plug-in
• Workflows synchrones
• Workflows asynchrones
• Activité de workflow personnalisée
• Personnaliser les actions
• Demandes de service web

Plug-ins synchrones (avant ou après l′opération : dans le contexte de transaction)

Lorsque des plug-ins sont enregistrés pour un événement, ils peuvent être enregistrés dans une étape d′Opération préalable ou de PostOperation qui se trouve dans la transaction. Toutes les demandes de messages du plug-in seront effectuées dans la transaction. Cela signifie que la durée de vie de la transaction, et de tous les verrous placés, sera prolongée.

Plug-ins synchrones (avant et après l′opération : dans le contexte de transaction)

Les plug-ins peuvent être enregistrés dans les phases d′Opération préalable et de PostOperation. Dans ce cas la transaction peut se prolonger encore parce qu′elle se prolonge dès le début du plug-in d′Opération préalable jusqu′à ce que le plug-in de PostOperation se termine.

Plug-ins synchrones (Validation préalable : hors du contexte de transaction)

Un plug-in peut également être enregistré pour agir en dehors de la transaction de plateforme en étant enregistré sur la phase de Validation préalable.

Notes

Il ne crée PAS sa propre transaction. Par conséquent, chaque demande de message dans le plug-in est traité indépendamment dans la base de données.

Ce scénario est applicable uniquement lorsque la Validation préalable est appelée comme première phase d′un pipeline d′événements. Même si le plug-in est enregistré dans la phase de Validation préalable, il est possible qu′il participe à une transaction comme la section suivante le décrit. Il ne peut pas être supposé qu′un plug-in de Validation préalable ne participe pas à une transaction, même s′il est possible de vérifier dans le contexte d′exécution si c′est le cas.

Plug-ins synchrones (Validation préalable : dans le contexte de transaction)

Le scénario associé se produit lorsqu′un plug-in de Validation préalable est enregistré mais que le pipeline d′événements associé est déclenché par une demande de message d′une transaction existante.

Lorsque le schéma suivant l′indique, créer un compte peut entraîner l′exécution d′un plug-in de Validation préalable en dehors d′une transaction lorsque la créaton initiale est effectuée. Si, dans le cadre du plug-in de validation, la demande de message est faite pour créer un compte enfant associé car ce deuxième pipeline d′événements est initialisé depuis pipeline parent, il participera à la même transaction.

Dans ce cas, le plug-in de Validation préalable détectera qu′une transaction existe déjà et participera à cette transaction même s′il est enregistré dans la phase de Validation préalable.

Comme mentionné précédemment, le plug-in peut vérifier le contexte d′exécution pour la propriété IsInTransaction, ce qui indique si ce plug-in s′exécute dans une transaction ou non.

Plug-ins asynchrones

Un plug-in peut également être enregistré pour agir de manière asynchrone. Dans ce cas, le plug-in agit également en dehors de la transaction de plateforme.

Notes

Le plug-in ne crée pas sa propre transaction ; chaque demande de message dans le plug-in est traitée de manière indépendante.

Résumé d′utilisation de transaction de plug-in

En résumé :

• Les plug-ins synchrones participent généralement aux transactions.
• Les plug-ins asynchrones ne participent jamais à une transaction de plateforme ; chaque demande est effectuée indépendamment.
• Les plug-ins de Validation préalable ne créent pas de transaction participent s′il en existe déjà une.

Événement	Nom de la phase	La transaction n′existe pas encore	La transaction existe déjà
Pré-événementiel	Validation préalable	Aucune transaction n′est créée. Ne pas participe à la transaction ; chaque demande utilise une transaction distincte de la base de données	Participe à la transaction existante
Pré-événementiel	Opération préalable	Participe à la transaction existante	Participe à la transaction existante
Post-événementiel	PostOperation	Participe à la transaction existante	Participe à la transaction existante
Asynchrone	S.O.	Aucune transaction n′est créée. Ne pas participe à la transaction ; chaque demande utilise une transaction distincte de la base de données	S.o.

Workflows synchrones

Du point de vue des transactions, les workflows synchrones agissent en tant que plug-ins de pré/post-opération. Ils agissent par conséquent dans la transaction de pipeline de la plateforme et peuvent avoir le même impact sur la durée de la transaction générale.

Workflows asynchrones

Les workflows asynchrones sont déclenchés en dehors de la transaction de plateforme.

Notes

Le workflow ne crée PAS non plus sa propre transaction et par conséquent chaque demande de message dans le workflow est traitée de manière indépendante.

Le diagramme suivant illustre le workflow asynchrone agissant à l′extérieur de la transaction de la plateforme et chaque étape initiant sa propre transaction distincte.

Activité de workflow personnalisée

Les activités de workflow personnalisées agissent dans le contexte du workflow parent.

• Workflow synchrone : agit dans la transaction
• Workflow asynchrone : agit en dehors de la transaction

Le diagramme suivant illustre les activités personnalisées agissant d′abord dans un workflow synchrone puis dans un workflow asynchrone.

Actions personnalisées

Les actions personnalisées peuvent créer leurs propres transactions. Il s′agit d′une fonctionnalité clé. Une action personnalisée peut créer une transaction distincte en dehors de l′étape de plateforme selon que elle est configurée pour activer la restauration.

• Activer la restauration défini
  • Si elle est appelée via une demande de message d′un plug-in s′exécutant dans la transaction, et que Activer la restauration est définie, l′action personnalisée agira au sein de la transaction existante.
  • Sinon, l′action personnalisée crée une nouvelle transaction et s′exécute dans celle-ci.
• Activer la restauration non défini
  • L′action personnalisée n′agira pas dans une transaction.

Demandes de service web

Lorsque des demandes sont effectuées en externe via des services Web, un pipeline est créé et le traitement de la transaction dans le pipeline se produit comme expliqué précédemment, mais une transaction n′est pas conservée une fois la réponse renvoyée. Puisque la durée s′écoulant avant la prochaine demande est inconnue, la plateforme n′autorise pas le verrouillage des ressources car cela bloqueraient d′autres activités.

Lorsque plusieurs demandes sont effectuées dans un plug-in utilisant le même contexte d′exécution, c′est le contexte d′exécution commun qui gère la référence de la transaction et dans les plug-ins synchrones garantit que chaque demande est faite dans la même transaction. La possibilité de maintenir un contexte d′exécution sur plusieurs demandes n′est pas disponible en dehors des plug-ins et par conséquent une transaction ne peut pas être maintenue dans les requêtes distinctes faites en externe.

Il existe deux messages spéciaux où plusieurs des actions peuvent être transmises à la plateforme Dataverse dans le cadre d′une seule demande de service web.

Message	Description
ExecuteMultiple	Cela permet à plusieurs actions indépendantes d′être transmises dans la même demande de service web. Chacune de ces demandes est effectuée indépendamment dans la plateforme de façon à ce qu′il n′y ait pas de contexte de transaction maintenu entre les demandes.
ExecuteTransaction	Cela permet de traiter plusieurs actions dans la même transaction de base de données, d′une façon similaire aux différentes demandes de message effectuées depuis un plug-in synchrone. Cette fonctionnalité aurait également des implications similaires aux demandes de messages multiples ; autrement dit, si chaque action dure longtemps (comme les requêtes coûteuses ou le déclenchement d′une longue chaîne de plug-ins ou de workflows synchrones associés) cela pourrait entraîner des problèmes de blocage sur la plateforme plus étendue.

Demandes d′API web (OData) dans les plug-ins

N′utilisez pas les demandes d′API web (OData) dans un plug-in dans la même organisation que le plug-in. Utilisez toujours les méthodes IOrganizationService. Cela permet la transmission du contexte de transaction afin que l′opération puisse participer à la transaction de pipeline.

Étapes suivantes

Outre les transactions de base de données, il est important de mesurer l′impact que plusieurs opérations de données simultanées peuvent avoir sur le système. Informations complémentaires : Conception de personnalisation évolutive : problèmes de concurrence

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).