Empêcher les mises à jour perdues

Nous commençons par le concept de blocage optimiste, qui est basé sur des ETags (balises d'entité). Pour activer les ETags pour une entité de modèle, ajoutez l'annotation @odata.etag à un élément de la définition d'entité.

Dans l'exemple illustré, l'élément modifiedAt de l'aspect géré est défini comme élément ETag à la fois pour l'entité Books et l'entité Authors. La directive annotate est utilisée à cet effet, ce qui permet d'annoter les définitions existantes.

L'idée d'un ETag est d'identifier une version spécifique d'une entité, dans notre exemple la version d'un livre ou d'un auteur. Cela peut être utilisé pour garantir l'intégrité des données, comme expliqué dans l'exemple suivant, sans utiliser de verrous.

Supposons que nous récupérions un auteur spécifique via la demande suivante car nous voulons modifier ses données :

1
GET Authors(18f76942-bfb3-40c5-8300-f999f14e9cc2)

Avec cette requête, la version de l'auteur, c'est-à-dire la valeur de l'élément ETag modifiedAt, est automatiquement retournée via l'en-tête de réponse HTTP ETag , par exemple :

1
ETag: W/"2024-03-15T11:30:48.069Z"

Pour réécrire les données modifiées sur l'auteur, la valeur ETag reçue est utilisée comme suit dans l'en-tête HTTP If-Match de la demande de modification correspondante :

1234567
PUT Authors(18f76942-bfb3-40c5-8300-f999f14e9cc2)
If-Match: W/"2024-03-15T11:30:48.069Z"
Content-Type: application/json

{ 
 ...
}

CAP vérifie ensuite si le contenu de l'élément modifiedAt a été modifié entre-temps. Si ce n'est pas le cas, les données de l'auteur sont modifiées dans la base de données et la zone modifiedAt ETag est mise à jour. Si oui, cela signifie que l'auteur a été modifié via une autre demande depuis la lecture des données. CAP interrompt donc la demande de modification et active le code de statut 412 (Échec de la condition préalable) pour la réponse HTTP. Le corps de la réponse contient une erreur similaire à ce qui suit :

12345
"error": {
  "code": "412",
  "message": "Precondition Failed",
  "@Common.numericSeverity": 4
}

Le verrouillage optimiste garantit l'intégrité des données en cas de modifications simultanées via différentes demandes.

Le verrouillage pessimiste, quant à lui, assure l'intégrité des données en cas de modifications simultanées via des transactions simultanées. Le blocage pessimiste vous permet de bloquer les données afin que d'autres transactions ne puissent pas les modifier de quelque manière que ce soit.

CAP exploite les blocages de base de données pour le blocage pessimiste, où une distinction est faite entre les blocages exclusifs et les blocages partagés.

Les enregistrements de données bloqués exclusivement ne peuvent pas être modifiés ni lus par d'autres transactions. Des blocages exclusifs sont activés lors de la lecture des enregistrements de données à partir de la base de données. L'API de requête de CAP fournit la méthode forUpdate() à cet effet.

Les blocages partagés empêchent également les mises à jour simultanées par les transactions parallèles. Cependant, elles permettent à toutes les transactions de lire les enregistrements de données bloqués.

Pour définir des blocages partagés, l'API de requête fournit la méthode forShareLock() .

Les verrous acquis (exclusifs ou partagés) sont libérés lorsque la transaction en cours est terminée, c'est-à-dire validés ou annulés.

Regardez la vidéo pour voir comment ajouter un contrôle d'exécution simultanée optimiste.