condition de course MISE À JOUR modification de la colonne de crédit - que se passe-t-il lors du rollback?

Question

ok, j'ai essayé de chercher et je n'ai pas trouvé de réponse à cela - je suis curieux de savoir comment le ROLLBACK gère les conditions de course. Par exemple:

Si j'ai une table (CompanyAccount) qui tient compte du nombre de crédits disponibles pour une entreprise (il n'y a qu'une seule ligne dans une table de base de données par société) et il y a potentiellement plusieurs utilisateurs entreprise qui peut décrémenter les crédits du compte unique de l'entreprise, que se passe-t-il en cas d'erreur lors d'un ROLLBACK?

Exemple:

Hypothèses: J'ai écrit la mise à jour correctement pour calculer le nouvel équilibre « crédit » au lieu de deviner ce que le nouveau solde créditeur est (autrement dit, nous essayons de ne pas dire l'instruction UPDATE ce que la nouvelle solde créditeur/valeur, nous disons prendre tout ce qui est dans la colonne de crédit et soustrayez ma valeur décrément dans l'instruction uPDATE) ...

ici est un exemple de la façon dont la déclaration de mise à jour est écrit:

MISE à jOUR dbo .CompanyAccount SET Credit = Crédit - @DecrementAmount O Company CompanyAccountId = @CompanyAccountId

Si la colonne "Crédit" contient 10 000 crédits. L'utilisateur A entraîne une diminution de 4 000 crédits et l'utilisateur B une diminution de 1 000 crédits. Pour une raison quelconque, une annulation est déclenchée pendant la décrémentation de l'utilisateur A (il y a environ une demi-douzaine de tables supplémentaires avec des lignes qui sont insérées pendant la TRANSACTION). Si l'utilisateur A gagne la condition de concurrence et que le nouveau solde est de 6000 (mais pas encore COMMITé), que se passe-t-il si le décrément de l'utilisateur B se produit avant que l'annulation ne soit appliquée? la colonne d'équilibre passe-t-elle de 6 000 à 5 000, puis ramène ROLLBACK à 10 000?

Je ne suis pas trop clair sur la façon dont le ROLLBACK va gérer cela. Peut-être que je simplifie trop. Quelqu'un peut-il me dire si je comprends mal comment ROLLBACK va fonctionner ou s'il y a d'autres risques dont je dois m'inquiéter pour ce style.

Merci de votre participation.

Answer 1

Dans l'exemple que vous avez donné, il n'y aura pas de problème.

La première transaction aura un verrou exclusif, ce qui signifie que la seconde ne peut pas modifier cette ligne tant que la première n'a pas été validée ou annulée. Il faudra juste attendre (bloqué) jusqu'à ce que le verrou soit libéré.

Cela devient un peu plus compliqué si vous avez plusieurs instructions. Vous devriez probablement lire sur différents niveaux d'isolement et comment ils peuvent permettre ou empêcher des phénomènes tels que des "mises à jour perdues".

Answer 2

La restauration fait partie de la transaction et les verrous seront conservés pendant la restauration. Le * A * tomique en ACIDE. L'utilisateur B ne démarre pas tant que tous les verrous ne sont pas relâchés.

Qu'est-ce qui se passe:

• utilisateur A verrouille les lignes
• L'utilisateur B ne verra pas les lignes jusqu'à ce que les verrous sont libérés
• utilisateur A annule, les verrous de libération, des changements n'a jamais eu lieu.
• L'utilisateur B voit les lignes.-1000 se traduira par 9000

Cependant, si l'utilisateur B a déjà lu la balance, il peut être incohérent quand il s'agit de UPDATE. Cela dépend de ce que vous faites réellement et dans quel ordre, d'où la nécessité de comprendre isolation levels (et les problèmes avec les lectures fantômes et non répétables)

Une alternative à REALABLE SERIALIZABLE ou REPEATABLE peut utiliser sp_getapplock en mode transaction aux parties sémaphores de la transaction.