Utilisation de transactions atomiques
Les scénarios suivants décrivent l'utilisation des transactions atomiques.
Scénario 1 : Une transaction atomique avec COM+ ServicedComponent
L’orchestration suivante montre comment utiliser RetryTransactionException avec des transactions atomiques. Bien qu'il ne soit pas possible d'inclure directement des gestionnaires d'exceptions dans une étendue atomique, cette étendue peut comporter une étendue non transactionnelle possédant un gestionnaire d'exceptions. ServicedComponent s’inscrit dans la même transaction DTC et toute exception levée par le composant est interceptée et levée à nouveau en tant que RetryTransactionException. (Cela suppose que la propriété Retry est définie sur True pour l’étendue atomique).
Notez que l’orchestration aurait été suspendue et que l’action dans la forme MessageAssignment aurait été restaurée même si l’exception RetryTransactionException n’a pas été levée. Ce modèle, toutefois, permet de renforcer la faculté de récupération de l'application dans laquelle les nouvelles tentatives ont lieu de façon automatique.
Transaction atomique avec COM+ ServicedComponent
Scénario 2 : Utilisation d’adaptateurs traités avec des transactions atomiques
L'orchestration suivante montre comment utiliser les transactions atomiques avec l'adaptateur SQL. L’orchestration entière est marquée comme longue avec des transactions atomiques individuelles pour les deux éléments de travail logiques : Insertion d’un nouveau client et Insérer les détails de la commande pour le client.
Si, pour une raison ou pour une autre, l'insertion de la commande (Order Insert) échoue, l'insertion du client (Customer Insert) doit être annulée. L'exemple utilise l'adaptateur SQL pour faire le travail de la base de données. Comme nous l'avons déjà vu, l'étendue associée à une transaction atomique se termine lorsque le message est envoyé à la base de données MessageBox. Cela implique qu'une fois que le moteur a réussi à envoyer le message dans les étendues Scope_InsertCustomer et Scope_InsertOrder, chaque étendue est validée. L'adaptateur SQL crée une transaction pour l'insertion du client ou la commande.
Les ports présentent une propriété « Notification d'envoi » pour valider l'envoi du message par le biais du port d'envoi. Lorsque la propriété Notification d'envoi est définie sur « Transmis », un abonnement de réception est placé avant le point de validation transactionnel de l'opération d'envoi. Cependant, dans le cas d'étendues atomiques, l'abonnement de réception est placé dans l'étendue parente englobante.
Si la transaction SQL InsertOrder échoue, un accusé de réception négatif (ou nack) est renvoyé et la « Scope_InsertOrder » est validée. Une fois que le port d'envoi a épuisé toutes les tentatives configurées, une exception DeliveryFailureException est générée. Cette exception est détectée par le gestionnaire d'exceptions par défaut, qui exécute le processus de compensation par défaut. Les gestionnaires de compensation associés à Scope_InsertCustomer et Scope_InsertOrder sont alors appelés, ce qui annule l'insertion des informations sur le client.
Notes
L'imbrication des deux étendues en une étendue à long terme et l'appel de la forme Compenser (qui cible la transaction à long terme) à partir du gestionnaire d'exceptions pour l'étendue à long terme aboutissent au résultat décrit ci-dessus. L'ensemble de l'orchestration ne peut pas être indiqué comme étant atomique car les transactions atomiques n'autorisent pas les transactions imbriquées.
Adaptateurs traités avec transactions atomiques
