Utilisation des valeurs de compartiment cumulées dans Entity Framework

Question

Je tente de trouver des modèles/stratégies de conception pour travailler avec des valeurs de compartiment cumulées dans une base de données où la concurrence peut poser problème. Je ne connais pas les termes de recherche à utiliser pour trouver des informations sur le sujet.

Voici mon cas d'utilisation (j'utilise le code-premier Entity Framework, donc des conseils spécifiques à l'EF est la bienvenue):

J'ai une table de base de données qui contient une valeur de quantité. Cette valeur de quantité peut être incrémentée ou décrémentée par plusieurs clients en même temps (pour cette raison, j'appelle cette valeur une valeur de "seau" car c'est un seau pour un tas d'activité accumulée, ce qui est en opposition avec l'autre stratégie où vous gardez toutes les activités et calculez la valeur en fonction de l'activité). Je cherche des stratégies pour assurer l'exactitude de cette valeur de "seau" (dans le contexte de EF) qui tient compte du fait que plusieurs clients peuvent essayer de le changer simultanément (concurrence).

La réponse «Vous devez suivre l'activité et en déduire la valeur de cette activité» est acceptable, mais je souhaite également prendre en compte toutes les solutions centrées sur les baies.

Je cherche des conseils sur les termes de recherche à utiliser pour trouver de bonnes informations sur ce sujet ainsi que des liens spécifiques.

Éditer: Vous pouvez supposer que toute l'activité est relative à la valeur du "seau" (aucun client n'apportera de changement absolu à la valeur, il ne fera que l'incrémenter ou la décrémenter).

Answer 1

Sans coder directement les requêtes SQL qui mettent à jour les compartiments, vous devez utiliser la simultanéité optimiste côté client. Voir Entity Framework Optimistic Concurrency Patterns. Les clients dont la mise à jour remplacerait une modification recevront une exception, après quoi vous pourrez recharger avec la valeur actuelle et réessayer. Ce modèle nécessite une colonne ROWVERSION sur la table cible.

Si vous codez les mises à jour en TSQL vous pouvez coder une mise à jour atomique, quelque chose comme

update foo with (updlock) 
set bucket_a = bucket_a + 1 
output inserted.* 
where id = @id 

(Le « UPDLOCK » est pas strictement nécessaire dans cette requête, mais elle est bonne forme chaque fois que vous voulez assurer ce type d'isolation)