Transactions distribuées avec WCF

Question

Architecture de base: n boîtiers physiques hébergeant chacun le même service WCF, assis derrière un équilibreur de charge. Chaque boîte touchant une infrastructure de base de données unique qui ne prend pas en charge les transactions - ne demandez pas: (

Donc, dans la couche d'accès aux données de mon application, j'ai besoin d'une méthode de transaction distribuée. Quelles sont mes options?

Notez que les clients de mon système seront des applications héritées communiquant via des services Web de base (BasicHttpBinding) et de nouveaux clients WCF brillants (NetTcpBinding ou NetNamedPipeBinding).

Modifier 1

E.g. il y aura un seul appel dans la couche WCF sur la boîte physique 1, par ex. EditEntity (...). Cet appel déclenchera 2 écritures dans la base de données. Après la première écriture, un autre client appelle EditEntity (...) pour la même entité sur une seconde instance de mon service WCF sur une seconde boîte physique. Dans la deuxième case, comment puis-je savoir qu'une transaction pour cette entité particulière est déjà en cours?

Merci.

Answer 1

Vous n'êtes pas sûr de nous avoir donné suffisamment d'argent pour continuer, mais si je lis correctement, vous essayez de vous assurer que vous pouvez supporter une transaction via votre service WCF? Alors que votre base de données ne prend pas en charge les transactions et que vos points de terminaison WCF se trouvent derrière un équilibreur de charge? Est-ce que j'ai ce correct? Si oui ....

Etant donné que votre base de données n’a pas de prise en charge transactionnelle, elle est déplacée vers votre niveau WCF. Cela suggère un niveau de granularité grossier dans vos méthodes, de sorte que vous pouvez vous assurer qu'un seul appel à votre service WCF englobe suffisamment votre transaction. Ne répartissez pas une transaction sur plusieurs appels WCF, vous vous posez des problèmes.

MISE À JOUR: Il existe des stratégies qui peuvent être utilisées avec des équilibreurs de charge qui assurent la persistance parmi les connexions, mais cela ne vous aidera pas ici. Si vous appelez consécutivement EditEntity () et que la première entrée consiste à lancer une transaction et que la seconde entrée consiste à effectuer une transaction ... alors votre service n’est pas suffisamment détaillé.

Consolidez ces deux appels en une seule méthode, à savoir EditEntityComplete ().

Y a-t-il une raison pour laquelle vous ne pouvez pas créer une méthode, par opposition à deux?

UPDATE # 2: Reformulation du problème - une seule méthode effectue des entrées dans une base de données qui ne prend pas en charge les transactions. La méthode en question exécute une série d'étapes qui doivent être complétées dans l'ordre. La méthode WCF représente des opportunités pour le conflit de concurrence d’enfreindre l’achèvement des étapes dans le bon ordre.

Sur cette base, en supposant que vous n’exigiez aucune donnée de retour de la fonction, considérons une file d’attente asynchrone pouvant enregistrer les demandes des points de terminaison WCF. Traitez ensuite la file d’attente à partir d’un seul processus en arrière-plan.

RÉVISION FINALE:

Reconsidérer la nécessité de ne pas modifier le magasin de données.

Compte tenu des exigences de plusieurs clients, de la mise à l'échelle, de l'équilibrage de la charge et de la prise en charge transactionnelle dans le magasin de données, une dernière suggestion: pousser pour modifier la base de données. Comprendre ceci est une exigence statique, mais vous déploierez beaucoup d'efforts pour essayer de mettre en œuvre un support transactionnel alors que de nombreuses plates-formes de base de données simples vous le fourniront. Essayer de recréer cette fonctionnalité a peu d’avantages, mais beaucoup d’inconvénients.