Dites que vous avez une application reliant 3 systèmes externes différents. Vous devez mettre à jour quelque chose dans tous 3. En cas de défaillance, vous devez reculer les opérations. Ce n'est pas une chose difficile à mettre en œuvre, mais dites que la fonctionnement 3 échoue, et lorsque vous retournez, le retour pour l'opération 1 échoue! Maintenant, le premier système externe est dans un état non valide ...
Je pense qu'une solution possible consiste à éteindre l'application et à forcer une solution manuelle du système externe, mais encore une fois ... il aurait peut-être déjà utilisé ces informations (et peut-être que c'est pourquoi il a échoué), ou nous pourrait ne pas avoir un accès suffisant. Ou ce n'est peut-être même pas un bon moyen de retourner l'action!
Y a-t-il de bonnes façons de manipuler de tels cas?
Edit: quelques détails de l'application ..
C'est une application Web multi-utilisateur. La plupart des travaux sont effectués avec des travaux planifiés (via Quartz.net), la plupart des opérations sont exécutées dans son propre thread. Certaines actions de l'utilisateur doivent résoudre des travaux qui mettent à jour plusieurs systèmes cependant. Les systèmes externes sont quelque peu instables.
Je pensais à changer l'application pour utiliser la commande et l'unité de modèle de travail
4 Réponses :
Selon la taille de l'application (utilisateur unique contre Enterprise), la fermeture de la demande pourrait être une mauvaise idée.
Tout d'abord, je suggérerais d'enregistrer l'état initial des informations modifiées dans les 3 applications externes au stockage local à votre propre application. Cela signifie que vous pouvez au moins déterminer ce que l'état de restauration est censé être si votre appsômé de l'application / la restauration échoue / etc. Une fois que la transaction s'est engagée avec succès, vous pouvez ensuite supprimer ces données.
Que faire lorsque l'une des opérations échoue dépend de la fonctionnalité des 3 systèmes externes. Supposons que l'un de ces systèmes détient des données d'employé. Arrêtez simplement l'application simplement parce que l'adresse d'un employé est erronée en raison d'une transaction échouée est surchargée. Il est bien préférable de simplement vérifier le journal des transactions ayant échoué (c.-à-d. Le stockage local auquel vous avez enregistré les états initiaux des 3 applications externes) chaque fois que les données d'un employé sont accessibles. Si ces données d'employés sont signalées comme invalides, lancez une erreur indiquant que l'enregistrement est dans un état non valide et ne peut pas être récupéré.
Toutefois, si l'ensemble du système externe sera projeté en désarroi par une transaction échouée, alors oui - il n'y a rien que vous puissiez faire ici mais fermez votre application jusqu'à ce que le problème soit corrigé.
COMMIT DE BIXPASSE ( 2PC ) peut convenir ici.
La première phase consiste à obtenir les différentes bases de données pour accepter qu'ils sont disposés à aller de l'avant avec le commit. Dans votre exemple, la base de données 1 ne procédera pas avec l'écriture avant que toutes les trois bases de données ont signalé que la transaction sera possible.
Ceci se compare au processus que vous décrivez qui est une approche "optimiste" - la base de données 1 supposera que la transaction devrait passer jusqu'à ce qu'elle apprenne au contraire, et est forcée de retourner.
Merci. C'est un peu ce que j'ai déjà utilisé une unité de travail avec exécuté, commettez-vous et la restauration qui stocke des commandes ayant une pirocession.
Voulez-vous expliquer davantage comment la restauration de l'opération 1 pourrait échouer?
L'état dans lequel il vise à atteindre est celui qu'il a été auparavant, il devrait donc être logiquement cohérent. Il pourrait y avoir des problèmes transitoires tels que l'échec du réseau, mais il est possible que le meilleur moyen de gérer cela soit de réessayer jusqu'à ce que les problèmes disparaissent.
Si le problème est que les transactions ultérieures sont verrouillées ou modifiées les données entre-temps, vous avez un problème beaucoup plus important - vos transactions ne sont pas atomiques et que les rougeurs de la puissance peuvent faire valoir que la production d'autres transactions deviennent invalides. < / p>
La réponse d'Oddthinking est une bonne chose, mais limitée car il est très difficile de de manière fiable faire un 2pc. Ceci est connu dans la communauté informatique distribuée pendant un certain temps, bien que beaucoup de gens font de leur mieux pour l'ignorer.
Si vous êtes intéressé par de développer plus profondément dans cette zone, le algorithme de consensus de Paxos est un bon endroit pour commencer. Et sachez que c'est un problème étonnamment difficile, précisément à cause des deux problèmes que vous faites allusion et du fait qu'il est en fait impossible de construire un système de messagerie vraiment fiable capable de délivrer un message dans une durée délimitée. (Pour comprendre pourquoi c'est vrai, considérez que Quelqu'un avec une pelle arrière < / a> peut effacer tous les liens réseau entre les différentes parties communicantes ...)
Je soupçonne que le correctif réel est la conception de l'architecture du système global et de la manière dont vous déployez des changements à l'autre de manière à ce que la perte de communication dans une zone ne soit pas catastrophique. Cela pourrait ou pourrait ne pas être facile à faire, en fonction des détails exacts.
Les systèmes externes sont-ils fixés? Ou pouvez-vous les modifier?