Utilisation de composants non transactionnels dans une transaction
Il est souvent utile de placer des composants non transactionnels dans une transaction pour tirer parti des propriétés ACID des transactions. Par exemple, si vous avez des composants hérités non transactionnels que vous utilisez pour mettre à jour les mots de passe sur un réseau, vous pouvez placer ces composants dans une transaction pour vous assurer que les mises à jour de mot de passe sont cohérentes sur le réseau.
L’objet de contexte transactionnel est un objet générique qui permet aux clients non transactionnels de combiner le travail de plusieurs objets COM en une seule transaction, sans vous obliger à développer un nouveau composant spécifiquement à cette fin. Contrairement à une transaction automatique, l’objet de contexte de transaction exige que son client valide explicitement la transaction ou l’abandonne.
Par défaut, la valeur de l’attribut de transaction de l’objet de contexte de transaction est définie sur Obligatoire. COM+ annule la transaction si le client libère l’objet de contexte de transaction sans émettre explicitement de commit ou d’abandon d’appel.
L’exemple Visual Basic suivant montre comment un client non transactionnel peut composer le travail effectué par plusieurs objets en une seule transaction :
Dim objTxCtx As TransactionContext
Dim objCat As MyDLL.Ccat ' Ccat is a user-defined component.
Dim objDog As MyDLL.Cdog ' Cdog is a user-defined component.
' Get TransactionContext object.
Set objTxCtx = _
CreateObject ("TxCtx.TransactionContext")
' Create instances of Cat and Dog.
Set objCat = _
objTxCtx.CreateInstance ("MyDLL.Ccat")
Set objDog = _
objTxCtx.CreateInstance ("MyDLL.Cdog")
' Both objects do work.
objDog.Bark
objCat.Hiss
' Commit the transaction.
objTxCtx.Commit
Limitations de l’objet contexte de transaction
Voici quelques limitations importantes de l’objet de contexte de transaction :
Lors de l’utilisation d’un objet de contexte transactionnel, la logique d’application qui combine le travail de plusieurs objets en une seule transaction est liée à une implémentation cliente non transactionnelle spécifique et certains avantages de l’utilisation de composants COM sont perdus. Ces avantages perdus sont les suivants :
- Possibilité de réutiliser la logique d’application dans le cadre d’une transaction encore plus volumineuse
- Imposition de la sécurité déclarative
- Flexibilité pour exécuter la logique à distance à partir du client
L’objet de contexte de transaction s’exécute in-process avec le client non transactionnel, ce qui signifie que COM+ doit être disponible sur l’ordinateur client non transactionnel. Cela peut ne pas être un problème, par exemple, lorsque l’objet de contexte de transaction est utilisé à partir d’une page ASP (Active Server Pages) qui s’exécute sur le même serveur que COM+.
Vous n’obtenez pas de contexte pour le client non transactionnel lorsque vous créez un objet de contexte de transaction. Le travail transactionnel ne peut être effectué qu’indirectement, par le biais d’objets COM créés à l’aide de l’objet de contexte de transaction. En particulier, le client non transactionnel ne peut pas utiliser des distributeurs de ressources COM+ (comme ODBC) et faire inclure le travail dans la transaction. Par exemple, les développeurs peuvent être familiarisés avec la syntaxe suivante pour effectuer un travail transactionnel sur des systèmes de base de données relationnelles :
BEGIN TRANSACTION DoWork COMMIT TRANSACTION
L’utilisation de l’objet de contexte de transaction d’une manière similaire ne produit pas le résultat souhaité :
Set objTxCtx = CreateObject ("TxCtx.TransactionContext") DoWork objTxCtx.Commit Set objTxCtx = Nothing
L’appel à DoWork dans cet exemple n’est pas inscrit dans une transaction. Au lieu de cela, vous devez créer un composant COM qui appelle DoWork, créer un objet instance de ce composant à l’aide de l’objet de contexte de transaction, puis appeler cet objet à partir du client non transactionnel pour que le travail fasse partie de la transaction contrôlée par le client.