Descripción de los componentes de TPS

Cualquier sistema de procesamiento de transacciones (TPS) que use el Administrador de transacciones de kernel (KTM) y el Sistema de archivos de registro común (CLFS) deben contener los siguientes componentes importantes:

• Un administrador de transacciones (KTM)

  KTM realiza un seguimiento del estado de cada transacción y coordina las operaciones de recuperación después de un bloqueo del sistema.

• Uno o varios administradores de recursos

  Los administradores de recursos, que proporciona, administran los datos asociados a cada transacción.

• Uno o varios flujos de registro clFS

  El administrador de transacciones y los administradores de recursos usan flujos de registro CLFS para registrar información que se puede usar para confirmar, revertir o recuperar una transacción.

• Uno o varios clientes transaccionales

  Normalmente, cada cliente transaccional del TPS puede crear una transacción, realizar operaciones en los datos en el contexto de la transacción y, a continuación, iniciar una operación de confirmación o reversión para la transacción.

En este tema se presenta un TPS simple con un administrador de recursos, un TPS más complejo que contiene varios administradores de recursos y otros escenarios de TPS.

La sección Using KTM (Uso de KTM ) proporciona información detallada sobre cómo usar KTM para crear componentes de TPS.

Simple TPS

Un TPS simple puede constar de KTM, un administrador de recursos y CLFS. Los clientes transaccionales pueden comunicarse con el administrador de recursos mediante una interfaz que proporciona el administrador de recursos.

Por ejemplo, supongamos que desea crear un sistema de administración de bases de datos. Quiere que los clientes del sistema accedan a la base de datos abriendo un identificador a un objeto de base de datos, realizando operaciones de lectura y escritura en el objeto y, a continuación, cerrando el identificador del objeto.

Ahora supongamos que desea que se produzcan conjuntos de operaciones de lectura y escritura de forma atómica para que otros usuarios del sistema solo vean el resultado final. Para lograr ese objetivo, diseñe un TPS que permita a los clientes enlazar conjuntos de operaciones de base de datos a una transacción.

El sistema debe incluir un administrador de recursos que administre los datos de la base de datos en respuesta a las solicitudes de lectura y escritura de los clientes. Este administrador de recursos podría exportar una interfaz de programación de aplicaciones (API) que permite a los clientes asociar una transacción con un conjunto de operaciones de lectura y escritura.

Cuando se carga el administrador de recursos, debe registrarse en KTM llamando a ZwCreateTransactionManager y ZwCreateResourceManager. A continuación, el administrador de recursos puede participar en transacciones.

Es posible que desee que el administrador de recursos admita un conjunto de funciones que permitan a los clientes crear objetos de datos, leer y escribir datos asociados a los objetos de datos y cerrar los objetos de datos. El siguiente pseudocódigo muestra una secuencia de código de ejemplo de un cliente.

CreateDataObject (IN TransactionID, OUT DataHandle);
ReadData (IN DataHandle, OUT Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
WriteData (IN DataHandle, IN Data);
CloseDataObject (IN DataHandle);

Para que un cliente pueda llamar a la rutina CreateDataObject del administrador de recursos, el cliente debe crear un objeto de transacción llamando a la rutina ZwCreateTransaction de KTM y obtener el identificador del objeto de transacción llamando a ZwQueryInformationTransaction.

Cuando el cliente llama a la rutina CreateDataObject del administrador de recursos, el cliente pasa el identificador del objeto de transacción al administrador de recursos. El administrador de recursos puede llamar a ZwOpenTransaction para obtener un identificador para el objeto de transacción y, a continuación, puede llamar a ZwCreateEnlistment para registrar su participación en la transacción.

En este momento, el cliente puede empezar a realizar operaciones en el objeto de datos. Dado que el cliente proporcionó un identificador de transacción cuando creó el objeto de datos, el administrador de recursos puede asignar todas las operaciones de lectura y escritura a la transacción.

El administrador de recursos debe registrar todos los resultados de las operaciones de datos que el cliente especifica sin hacer que los resultados sean permanentes. Normalmente, el administrador de recursos usa CLFS para registrar los resultados de la operación en un flujo de registro de transacciones.

Cuando el cliente haya terminado de llamar al administrador de recursos para realizar operaciones transaccionales, llama a la rutina ZwCommitTransaction de KTM. En este momento, KTM notifica al administrador de recursos que debe hacer que las operaciones sean permanentes. A continuación, el administrador de recursos mueve los resultados de la operación del flujo de registro al medio de almacenamiento permanente de los datos. Por último, el administrador de recursos llama a ZwCommitComplete para informar a KTM de que la operación de confirmación está completa.

¿Qué ocurre si el administrador de recursos notifica un error para una de las llamadas del cliente a ReadData o WriteData? El cliente puede llamar a ZwRollbackTransaction para revertir la transacción. Como resultado de esa llamada, KTM notifica al administrador de recursos que debe restaurar los datos en su estado original. A continuación, el cliente puede crear una nueva transacción para las mismas operaciones o puede optar por no continuar.

El siguiente pseudocódigo muestra un ejemplo de una secuencia más detallada de las operaciones transaccionales de un cliente.

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    CreateDataObject (TransactionID, &DataHandle);
    Status = ReadData (DataHandle, &Data1);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data2);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data3);
    if (Status == Error) goto ErrorRollback;
    Status = WriteData (DataHandle, Data4);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

¿Qué ocurre si el sistema se bloquea después de crear la transacción, pero antes de confirmarla o revertirla? Cada vez que se cargue el administrador de recursos, debe llamar a ZwRecoverTransactionManager y ZwRecoverResourceManager. Llamar a ZwRecoverTransactionManager hace que KTM abra su flujo de registro y lea el historial de transacciones. La llamada a ZwRecoverResourceManager hace que KTM notifique al administrador de recursos las transacciones en curso que estaban en curso antes del bloqueo y las transacciones que el administrador de recursos debe recuperar.

Si un cliente transaccional llamado ZwCommitTransaction para una transacción antes del bloqueo y comenzó a controlar las operaciones de confirmación de la transacción, el administrador de recursos debe poder restaurar el estado de la transacción al punto inmediatamente antes del bloqueo. Si el cliente no estaba listo para confirmar la transacción antes del bloqueo, el administrador de recursos puede descartar los datos y revertir la transacción.

Para obtener más información sobre cómo escribir clientes transaccionales, vea Crear un cliente transaccional.

Para obtener más información sobre cómo escribir administradores de recursos, consulte Creación de un Resource Manager.

Varios administradores de recursos en un TPS

Ahora supongamos que el TPS permite a los clientes modificar la información en dos bases de datos independientes dentro de una sola transacción, de modo que la transacción solo se realice correctamente si las modificaciones de ambas bases de datos se realizan correctamente.

En este caso, el TPS puede tener dos administradores de recursos, uno para cada base de datos. Cada administrador de recursos puede exportar una API que los clientes pueden usar para acceder a la base de datos del administrador de recursos.

El siguiente pseudocódigo muestra cómo un cliente puede crear una sola transacción que contenga operaciones en dos bases de datos que dos administradores de recursos admiten.

En este ejemplo, el cliente lee datos de la primera base de datos y los escribe en la segunda base de datos. A continuación, el cliente lee los datos de la segunda base de datos y los escribe en la primera base de datos. (El primer administrador de recursos exporta funciones que comienzan por Rm1 y la segunda función de exportación de Resource Manager que comienza por Rm2).

    ZwCreateTransaction (&TransactionHandle, ...);
    ZwQueryInformationTransaction (TransactionHandle, ...);
    Rm1CreateDataObject (TransactionID, &Rm1DataHandle);
    Rm2CreateDataObject (TransactionID, &Rm2DataHandle);
    Status = Rm1ReadData (Rm1DataHandle, &Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2WriteData (Rm2DataHandle, Rm1Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm2ReadData (Rm2DataHandle, &Rm2Data);
    if (Status == Error) goto ErrorRollback;
    Status = Rm1WriteData (Rm1DataHandle, Rm2Data);
    if (Status == Error) goto ErrorRollback;
    ZwCommitTransaction (TransactionHandle, ...);
    goto Leave;
ErrorRollback:
    ZwRollbackTransaction (TransactionHandle, ...);
Leave:
    ZwClose (TransactionHandle);
    return;

Dado que el cliente pasa el mismo identificador de transacción a ambos administradores de recursos, ambos administradores de recursos pueden llamar a ZwOpenTransaction y ZwCreateEnlistment para inscribirse en la transacción. Cuando el cliente llama finalmente a ZwCommitTransaction, KTM notifica a cada administrador de recursos que el administrador debe hacer permanente las operaciones y cada administrador de recursos llama a ZwCommitComplete cuando haya terminado.

Otros escenarios de TPS

KTM admite otros escenarios de TPS. Por ejemplo, en los escenarios siguientes se describen los componentes que un TPS podría contener:

• Un administrador de recursos que administra varias bases de datos.

  La API de Resource Manager podría permitir que los clientes abran y accedan a más de una base de datos a la vez, y el cliente podría combinar accesos a varias bases de datos en una sola transacción.

• Un administrador de recursos con una API a la que los clientes llaman y administradores de recursos adicionales con LAS API a las que llama el primer administrador de recursos.

  El cliente solo se comunica con el primer administrador de recursos. Cuando ese administrador de recursos procesa las solicitudes de un cliente, puede acceder a los administradores de recursos adicionales, según sea necesario, para procesar las solicitudes del cliente. Por ejemplo, un administrador de recursos administra una base de datos accesible para el cliente que requiere operaciones de comprobación de datos o de copia de seguridad desde un segundo administrador de recursos que no está disponible para los clientes.

• Un cliente existente y un administrador de recursos que no usan KTM, integrados con un conjunto adicional de administradores de recursos que usan KTM.

  En este caso, normalmente tiene que modificar el administrador de recursos existente para que se convierta en un administrador de transacciones superior que se comunique con KTM.