Noções básicas sobre componentes TPS

Qualquer sistema de processamento de transações (TPS) que use o Kernel Transaction Manager (KTM) e o Common Log File System (CLFS) deve conter os seguintes componentes importantes:

• Um gestor de transações (KTM)

  A KTM rastreia o estado de cada transação e coordena as operações de recuperação após uma falha do sistema.

• Um ou mais gestores de recursos

  Os gerentes de recursos que você fornece gerenciam os dados associados a cada transação.

• Um ou mais fluxos de log CLFS

  O gerenciador de transações e os gerentes de recursos usam fluxos de log CLFS para registrar informações que podem usar para confirmar, reverter ou recuperar uma transação.

• Um ou mais clientes transacionais

  Normalmente, cada cliente transacional do seu TPS pode criar uma transação, executar operações em dados dentro do contexto da transação e, em seguida, iniciar uma operação de confirmação ou reversão para a transação.

Este artigo apresenta um TPS simples com um gerenciador de recursos, um TPS mais complexo que contém vários gerenciadores de recursos e alguns outros cenários de TPS.

A secção Utilizar a KTM fornece informações detalhadas sobre como utilizar a KTM para criar componentes TPS.

TPS simples

Um TPS simples pode consistir em KTM, um gerenciador de recursos e CLFS. Os clientes transacionais podem se comunicar com o gerenciador de recursos por meio de uma interface fornecida pelo gerenciador de recursos.

Por exemplo, suponha que você queira criar um sistema de gerenciamento de banco de dados. Você deseja que os clientes do sistema acessem o banco de dados abrindo um identificador para um objeto de banco de dados, executando operações de leitura e gravação no objeto e, em seguida, fechando o identificador de objeto.

Agora suponha que você queira que conjuntos de operações de leitura e gravação ocorram atomicamente para que outros usuários do sistema vejam apenas o resultado final. Você pode atingir essa meta projetando um TPS que permita aos clientes vincular conjuntos de operações de banco de dados a uma transação.

Seu sistema deve incluir um gerenciador de recursos que gerencie os dados no banco de dados em resposta a solicitações de leitura e gravação de clientes. Esse gerenciador de recursos pode exportar uma interface de programação de aplicativo (API) que permite aos clientes associar uma transação a um conjunto de operações de leitura e gravação.

Quando você carrega seu gerenciador de recursos, ele deve se registrar na KTM chamando ZwCreateTransactionManager e ZwCreateResourceManager. Em seguida, o gerente de recursos pode participar de transações.

Talvez você queira que seu gerenciador de recursos ofereça suporte a um conjunto de funções que permitem que os clientes criem objetos de dados, leiam e gravem dados associados aos objetos de dados e fechem os objetos de dados. O pseudocódigo a seguir mostra uma sequência de código de exemplo de um 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);

Antes que um cliente possa chamar a rotina CreateDataObject do seu gerenciador de recursos, o cliente deve criar um objeto de transação chamando a rotina ZwCreateTransaction da KTM e obter o identificador do objeto de transação chamando ZwQueryInformationTransaction.

Quando o cliente chama a rotina CreateDataObject do gerenciador de recursos, o cliente passa o identificador do objeto de transação para o gerenciador de recursos. O gerenciador de recursos pode chamar ZwOpenTransaction para obter um identificador para o objeto de transação e, em seguida, pode chamar ZwCreateEnlistment para registrar sua participação na transação.

Neste ponto, o cliente pode começar a executar operações no objeto de dados. Como o cliente forneceu um identificador de transação quando criou o objeto de dados, o gerenciador de recursos pode atribuir todas as operações de leitura e gravação à transação.

Seu gerente de recursos deve registrar todos os resultados das operações de dados que o cliente especifica sem tornar os resultados permanentes. Normalmente, o gerenciador de recursos usa CLFS para registrar os resultados da operação em um fluxo de log de transações.

Quando o cliente termina de chamar o gestor de recursos para executar operações transacionais, chama a rotina ZwCommitTransaction da KTM. Neste ponto, a KTM notifica o gestor de recursos de que deve tornar as operações permanentes. Em seguida, o gerenciador de recursos move os resultados da operação do fluxo de log para o meio de armazenamento permanente dos dados. Finalmente, o gestor de recursos chama ZwCommitComplete para informar a KTM de que a operação de confirmação está concluída.

O que acontece se o seu gestor de recursos comunicar um erro para uma das chamadas do cliente para ReadData ou WriteData? O cliente pode chamar ZwRollbackTransaction para reverter a transação. Como resultado dessa chamada, a KTM notifica o gestor de recursos de que deve restaurar os dados para o seu estado original. Em seguida, o cliente pode criar uma nova transação para as mesmas operações ou optar por não continuar.

O pseudocódigo a seguir mostra um exemplo de uma sequência mais detalhada das operações transacionais de um 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;

O que acontece se o sistema falhar após a transação ser criada, mas antes de ser confirmada ou revertida? Sempre que o gerenciador de recursos carregar, ele deve chamar ZwRecoverTransactionManager e ZwRecoverResourceManager. Chamar ZwRecoverTransactionManager faz com que a KTM abra seu fluxo de log e leia o histórico de transações. Chamar ZwRecoverResourceManager faz com que a KTM notifique o gestor de recursos de quaisquer transações alistadas que estavam em curso antes da falha e quais as transações que o gestor de recursos deve, portanto, recuperar.

Se um cliente transacional chamar ZwCommitTransaction para uma transação antes da falha e começar a lidar com operações de confirmação para a transação, o gestor de recursos deve ser capaz de restaurar o estado da transação ao ponto imediatamente antes da falha. Se o cliente não estava pronto para confirmar a transação antes da falha, o gerente de recursos pode descartar os dados e reverter a transação.

Para obter mais informações sobre como escrever clientes transacionais, consulte Criando um cliente transacional.

Para obter mais informações sobre como escrever gerenciadores de recursos, consulte Criando um gerenciador de recursos.

Vários gerentes de recursos em um TPS

Agora, suponha que seu TPS permita que os clientes modifiquem informações em dois bancos de dados separados dentro de uma única transação, de modo que a transação seja bem-sucedida somente se as modificações de ambos os bancos de dados forem bem-sucedidas.

Nesse caso, seu TPS pode ter dois gerenciadores de recursos, um para cada banco de dados. Cada gerente de recursos pode exportar uma API que os clientes podem usar para acessar o banco de dados do gerenciador de recursos.

O pseudocódigo a seguir mostra como um cliente pode criar uma única transação que contém operações em dois bancos de dados suportados por dois gerentes de recursos.

Neste exemplo, o cliente lê dados do primeiro banco de dados e os grava no segundo banco de dados. Em seguida, o cliente lê dados do segundo banco de dados e grava-os no primeiro banco de dados. (O primeiro gerenciador de recursos exporta funções que começam com Rm1 e o segundo gerenciador de recursos exporta funções que começam com 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;

Como o cliente passa o mesmo identificador de transação para ambos os gerentes de recursos, ambos os gerentes de recursos podem chamar ZwOpenTransaction e ZwCreateEnlistment para se alistar na transação. Quando o cliente eventualmente chama ZwCommitTransaction, a KTM notifica cada gerente de recursos que o gerente deve tornar as operações permanentes, e cada gerente de recursos chama ZwCommitComplete quando terminar.

Outros cenários TPS

A KTM suporta outros cenários TPS. Por exemplo, os cenários a seguir descrevem componentes que um TPS pode conter:

• Um gerenciador de recursos que gerencia vários bancos de dados.

  A API do gerenciador de recursos pode permitir que os clientes abram e acessem mais de um banco de dados ao mesmo tempo, e o cliente pode combinar acessos a vários bancos de dados em uma única transação.

• Um gestor de recursos com uma API que os clientes chamam e outros gestores de recursos com APIs que o primeiro gestor de recursos chama.

  O cliente se comunica apenas com o primeiro gerente de recursos. Quando esse gerente de recursos processa solicitações de um cliente, ele pode acessar os gerentes de recursos adicionais, conforme necessário, para processar as solicitações do cliente. Por exemplo, um gerente de recursos gerencia um banco de dados acessível pelo cliente que requer operações de backup ou verificação de dados de um segundo gerenciador de recursos que os clientes não podem acessar.

• Um cliente existente e um gestor de recursos que não utilizam a KTM, integrados com um conjunto adicional de gestores de recursos que utilizam a KTM.

  Neste caso, normalmente tem de modificar o gestor de recursos existente para que este se torne num gestor de transações superior que comunica com a KTM.