Les transactions distribuées signifient que les participants aux transactions, les serveurs prenant en charge les transactions, les serveurs de ressources et les gestionnaires de transactions sont situés sur différents nœuds dans différents systèmes distribués.
Afin de mettre en œuvre des transactions distribuées, le protocole de validation en deux phases présenté ci-dessous doit être utilisé. * Phase 1 : Commencez à envoyer des informations de pré-validation à toutes les ressources impliquées dans la transaction. A ce moment, les ressources impliquées dans la transaction ont une dernière chance de terminer anormalement la transaction. Si une ressource décide de terminer anormalement la transaction, la totalité de la transaction est annulée et la ressource ne sera pas mise à jour. Sinon, la transaction s'exécutera normalement, sauf en cas d'échec catastrophique. Pour éviter toute panne catastrophique, toutes les mises à jour de ressources sont écrites dans le journal. Ces journaux sont persistants, ils survivent donc à une panne et peuvent être à nouveau mis à jour pour toutes les ressources. * Phase 2 : Se produit uniquement lorsque la phase 1 ne se termine pas anormalement. À ce stade, tous les gestionnaires de ressources pouvant être localisés et contrôlés individuellement commenceront à effectuer de véritables mises à jour des données. Dans le protocole de validation en deux phases des transactions distribuées, il existe un gestionnaire de transactions principal chargé d'agir en tant que coordinateur des transactions distribuées. Le coordinateur de transactions est responsable de l'ensemble de la transaction et la fait travailler avec les autres gestionnaires de transactions du réseau. Afin de mettre en œuvre des transactions distribuées, un protocole doit être utilisé pour transférer les informations de contexte de transaction entre différents participants à une transaction distribuée. IIOP est un tel protocole. Cela nécessite que les participants aux transactions développés par différents développeurs prennent en charge un protocole standard pour réaliser des transactions distribuées.
La structure d'une transaction distribuée démarrée dans Transact-SQL est relativement simple :
1. Un script Transact-SQL ou une connexion d'application exécute l'instruction Transact-SQL qui démarre la transaction distribuée.
2. Le Microsoft® SQL Server™ exécutant l'instruction devient le serveur maître de la transaction.
3. Le script ou l'application exécute ensuite une requête distribuée sur le serveur lié, ou une procédure stockée distante sur le serveur distant.
4. Lorsqu'une requête distribuée ou un appel de procédure distante est exécuté, le serveur maître appellera automatiquement MS DTC pour enregistrer les serveurs liés et les serveurs distants dans la transaction distribuée.
5. Lorsqu'un script ou une application émet une instruction COMMIT ou ROLLBACK, le serveur SQL maître appellera MS DTC pour gérer le processus de validation en deux phases, ou informera les serveurs liés et les serveurs distants d'annuler leurs transactions.
Déclarations
Il existe très peu d'instructions Transact-SQL qui contrôlent les transactions distribuées, car la plupart du travail est effectué en interne par Microsoft® SQL Server™ et MS DTC. Les seules instructions Transact-SQL requises dans un script ou une application Transact-SQL sont :
● Démarrer une transaction distribuée.
● Effectuez des requêtes distribuées sur des serveurs liés ou des appels de procédure à distance sur des serveurs distants.
● Appelez l'instruction standard Transact-SQL COMMIT TRANSACTION, COMMIT WORK, ROLLBACK TRANSACTION ou ROLLBACK WORK pour terminer la transaction.
●Pour toute transaction distribuée Transact-SQL, le serveur SQL traitant le script ou la connexion Transact-SQL appellera automatiquement MS DTC pour coordonner la validation ou l'annulation de la transaction.
L'option REMOTE_PROC_TRANSACTIONS est une option de compatibilité qui affecte uniquement les appels de procédures stockées distantes effectuées vers des serveurs distants définis à l'aide de sp_addserver. Pour plus d’informations sur les procédures stockées distantes, consultez Architecture des procédures stockées distantes. Cette option ne s'applique pas aux requêtes distribuées qui exécutent des procédures stockées sur des serveurs liés définis à l'aide de sp_addlinkedserver. Pour plus d’informations sur les requêtes distribuées, consultez Requêtes distribuées.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!