Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’APPLIQUE À : 
NoSQL
Les transactions de base de données offrent un modèle de programmation prédictif et sécurisé pour gérer les modifications simultanées des données. Les bases de données relationnelles traditionnelles, telles que SQL Server, vous permettent d’écrire la logique métier à l’aide de procédures stockées et de déclencheurs, puis de l’envoyer au serveur pour l’exécution directement dans le moteur de base de données.
Avec les bases de données relationnelles traditionnelles, vous devez gérer deux langages de programmation différents : un langage de programmation d’application nontransactionnel, tel que JavaScript, Python, C# ou Java ; et un langage de programmation transactionnel, tel que T-SQL, qui est exécuté en mode natif par la base de données.
Le moteur de base de données dans Azure Cosmos DB prend en charge les transactions compatibles ACID complètes (atomicité, cohérence, isolation, durabilité) avec l’isolation d’instantané. Toutes les opérations de base de données dans l’étendue de la partition logique d’un conteneur sont exécutées de manière transactionnelle dans le moteur de base de données hébergé par le réplica de la partition. Ces opérations comprennent à la fois les opérations d’écriture (mise à jour d’un ou de plusieurs éléments dans la partition logique) et de lecture.
Le tableau suivant répertorie les différentes opérations et types de transactions :
| opération | Type d’opération | Transaction unique ou multi-élément |
|---|---|---|
| Insérer (sans pré/postdéclencheur) | Écrire | Transaction à un seul élément |
| Insérer (avec pré/postdéclencheur) | Écrire et lire | Transaction à plusieurs éléments |
| Remplacer (sans pré/postdéclencheur) | Écrire | Transaction à un seul élément |
| Remplacer (avec pré/postdéclencheur) | Écrire et lire | Transaction à plusieurs éléments |
| Upsert (sans pré/postdéclencheur) | Écrire | Transaction à un seul élément |
| Upsert (avec pré/postdéclencheur) | Écrire et lire | Transaction à plusieurs éléments |
| Supprimer (sans pré/postdéclencheur) | Écrire | Transaction à un seul élément |
| Supprimer (avec pré/postdéclencheur) | Écrire et lire | Transaction à plusieurs éléments |
| Exécuter une procédure stockée | Écrire et lire | Transaction à plusieurs éléments |
| Exécution lancée par le système d’une procédure de fusion | Écrire | Transaction à plusieurs éléments |
| Exécution lancée par le système de la suppression des éléments en fonction de l’expiration (durée de vie ou TTL) d’un élément | Écrire | Transaction à plusieurs éléments |
| Lire | Lire | Transaction à un seul élément |
| Flux de modification | Lire | Transaction à plusieurs éléments |
| Lecture paginé | Lire | Transaction à plusieurs éléments |
| Requête paginé | Lire | Transaction à plusieurs éléments |
| Exécuter une fonction définie par l’utilisateur dans le cadre de la requête paginée | Lire | Transaction à plusieurs éléments |
Transactions à plusieurs éléments
Azure Cosmos DB vous permet d’écrire des procédures stockées, des déclencheurs et des fonctions définies par l’utilisateur et des procédures de fusion dans JavaScript. Azure Cosmos DB prend en charge en mode natif l’exécution de JavaScript à l’intérieur de son moteur de base de données. Vous pouvez inscrire des procédures stockées, des pré/post-déclencheurs, des fonctions définies par l’utilisateur (UDF) et des procédures de fusion sur un conteneur et les exécuter ultérieurement dans le moteur de base de données Azure Cosmos DB. L’écriture de la logique d’application en JavaScript permet une expression naturelle du flux de contrôle, de l’étendue variable, de l’attribution et de l’intégration des primitives de gestion des exceptions au sein des transactions de base de données directement dans le langage JavaScript.
Les procédures stockées, déclencheurs, fonctions définies par l’utilisateur et procédures de fusion JavaScript sont inclus dans une transaction ACID ambiante avec un isolement de capture instantanée dans tous les éléments de la partition logique. Pendant son exécution, si le programme JavaScript lève une exception, la transaction entière est abandonnée et restaurée. Le modèle de programmation obtenu est simple, mais puissant. Les développeurs JavaScript obtiennent un modèle de programmation durable tout en continuant d’utiliser les constructions de langage et les primitives de bibliothèques qui leurs sont familières.
La possibilité d’exécuter JavaScript directement dans le moteur de base de données offre une exécution performante et transactionnelle des opérations de base de données sur les éléments d’un conteneur. En outre, étant donné que le moteur de base de données Azure Cosmos DB prend en charge en mode natif JSON et JavaScript, il n’existe aucune incompatibilité d’impedance entre les systèmes de type d’une application et la base de données.
Contrôle de concurrence optimiste
Le contrôle de concurrence optimiste (OCC) vous permet d’empêcher les mises à jour et les suppressions non prises en compte. Les opérations simultanées en conflit sont soumises au verrouillage pessimiste standard du moteur de base de données hébergé par la partition logique qui détient l’élément. Lorsque deux opérations simultanées tentent de mettre à jour la dernière version d’un élément dans une partition logique, l’une d’elles gagne et l’autre échoue. Toutefois, si une ou deux opérations tentant de mettre à jour simultanément le même élément avait précédemment lu une valeur plus ancienne de l’élément, la base de données ne sait pas si la valeur précédemment lue par l’une ou l’autre des opérations en conflit était en effet la dernière valeur de l’élément.
Heureusement, cette situation peut être détectée avec l’OCC avant de laisser les deux opérations entrer dans la limite de transaction à l’intérieur du moteur de base de données. L’OCC protège vos données contre les modifications accidentelles qui ont été apportées par d’autres personnes. Il empêche également d’autres personnes d’écraser accidentellement vos propres modifications.
Implémenter un contrôle de concurrence optimiste à l’aide d’en-têtes HTTP et ETag
Chaque élément stocké dans un conteneur Azure Cosmos DB dispose d’une propriété _etag définie par le système. La valeur de _etag est automatiquement générée et mise à jour par le serveur chaque fois que l’élément est mis à jour. La propriété _etag peut être utilisée avec l’en-tête de requête if-match fourni par le client pour permettre au serveur de déterminer si un élément peut être mis à jour de manière conditionnelle. Si la valeur de l’en-tête if-match correspond à la valeur du _etag serveur, l’élément est ensuite mis à jour. Si la valeur de l’en-tête de requête if-match n’est plus actuelle, le serveur rejette l’opération avec un message de réponse de type « HTTP 412 Échec de la condition préalable ». Le client peut alors réextraire l’élément pour acquérir sa version actuelle sur le serveur ou remplacer la version de l’élément sur le serveur par sa propre valeur _etag pour l’élément. De plus, la propriété _etag peut être utilisée avec l’en-tête if-none-match pour déterminer si la nouvelle extraction d’une ressource est nécessaire.
La valeur _etag de l’élément change chaque fois que l’élément est mis à jour. Pour les opérations de remplacement d’élément, if-match doit être exprimé explicitement dans le cadre des options de requête. Pour obtenir un exemple, consultez l’exemple de code dans GitHub. Les valeurs _etag sont implicitement vérifiées pour tous les éléments écrits touchés par la procédure stockée. Si un conflit est détecté, la procédure stockée annule la transaction et génère une exception. Avec cette méthode, l’ensemble ou aucune des écritures dans la procédure stockée sont appliquées de façon atomique. Il s’agit d’un signal à l’application pour réappliquer les mises à jour et réessayer la demande du client d’origine.
Contrôle d’accès concurrentiel optimiste et distribution mondiale
Les mises à jour simultanées d’un élément sont soumises au contrôle d’accès concurrentiel optimiste par la couche de protocole de communication d’Azure Cosmos DB. Pour les comptes Azure Cosmos DB configurés pour les écritures à région unique, Azure Cosmos DB garantit que la version côté client de l’élément que vous mettez à jour (ou supprimez) est identique à la version de l’élément dans le conteneur Azure Cosmos DB. Cela garantit que vos écritures sont protégées contre tout remplacement involontaire par les écritures d’autres utilisateurs, et inversement. Dans un environnement multi-utilisateur, le contrôle d’accès concurrentiel optimiste vous protège contre la suppression accidentelle ou la mise à jour de la version incorrecte d’un élément. Par conséquent, les éléments sont protégés contre les problèmes notoires de « perte de mise à jour » ou de « perte de suppression ».
Dans un compte Azure Cosmos DB configuré pour des écritures multirégions, les données peuvent être validées indépendamment dans les régions secondaires si _etag correspond à celui des données dans la région locale. Une fois les nouvelles données validées localement dans une région secondaire, elles sont ensuite fusionnées dans le hub ou la région primaire. Si la stratégie de résolution des conflits fusionne les nouvelles données dans la région hub, ces données sont ensuite répliquées globalement avec la nouvelle _etag. Si la stratégie de résolution de conflit rejette les nouvelles données, la région secondaire est restaurée aux données d’origine et _etag.
Étapes suivantes
En savoir plus sur les transactions de base de données et le contrôle de concurrence optimiste :