¿Cómo funcionan las transacciones distribuidas (por ejemplo, MSDTC)?

Question

Entiendo, de una manera borrosa, cómo funcionan las transacciones ACID regulares. Realiza algún trabajo en una base de datos de tal forma que el trabajo no se confirma hasta que se establece algún tipo de indicador de confirmación. La parte de confirmación se basa en una suposición subyacente (como una escritura de bloque de disco único es atómica). En el caso de un error catastrófico, puede borrar los datos no confirmados en la fase de recuperación.

¿Cómo funcionan las transacciones distribuidas? En algunos de los documentos de MS he leído que de alguna manera puede realizar una transacción entre bases de datos y sistemas de archivos (entre otras cosas).

Esta tecnología podría (y probablemente) utilizarse para los instaladores, donde desea que el programa esté completamente instalado o ausente por completo. Simplemente comienza una transacción al inicio del instalador. A continuación, puede conectarse al registro y al sistema de archivos, realizando los cambios que definen la instalación. Cuando el trabajo finalice, simplemente confirme o deshaga si la instalación falla por alguna razón. El registro y el sistema de archivos se limpian automáticamente para usted por este coordinador de transacciones distribuidas mágico.

¿Cómo es posible que dos sistemas dispares se puedan tramitar de esta manera? Me parece que siempre es posible dejar el sistema en un estado incoherente, donde el sistema de archivos ha cometido sus cambios y el registro no. Creo que en MSDTC incluso es posible realizar una transacción en la red.

He leído http://blogs.msdn.com/florinlazar/archive/2004/03/04/84199.aspx, pero parece ser solo el comienzo de la explicación, y ese paso 4 debería ampliarse considerablemente.

Editar: De lo que se reúnen en http://en.wikipedia.org/wiki/Distributed_transaction, puede llevarse a cabo mediante una confirmación en dos fases (http://en.wikipedia.org/wiki/Two-phase_commit). Después de leer esto, todavía no entiendo el método al 100%, parece que hay mucho margen de error entre los pasos.

Answer 1

Acerca de "paso 4":

El administrador de transacciones coordenadas con los gestores de recursos para asegurar que todos tienen éxito para hacer el pedido trabajo o ninguno de los trabajos si se hace, por lo tanto mantener la ÁCIDO propiedades.

Esto, por supuesto, requiere que todos los participantes proporcionen las interfaces adecuadas y las implementaciones (sin errores). La interfaz se parece vagamente esto:

public interface ITransactionParticipant { 
    bool WouldCommitWork(); 
    void Commit(); 
    void Rollback(); 
} 

el administrador de transacciones durante la confirmación en tiempo consulta todos los participantes si están dispuestos a confirmar la transacción. Los participantes solo pueden afirmar esto si pueden comprometer esta transacción en todas las condiciones de error permisibles (validación, errores del sistema, etc.). Después de que todos los participantes hayan afirmado la posibilidad de comprometer la transacción, el administrador envía el mensaje Commit() a todos los participantes. Si, en cambio, un participante genera un error o agota el tiempo de espera, la transacción se anula y los miembros individuales se revierten.

Este protocolo requiere que los participantes graben todo el contenido de sus transacciones antes de afirmar su capacidad para comprometerse. Por supuesto, esto tiene que estar en una estructura de registro de transacciones local especial para poder recuperarse de varios tipos de fallas.