Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os componentes transacionais que devem ser agrupados têm requisitos especiais.
Recrutando recursos manualmente
Os objetos agrupáveis que participam de transações devem recrutar manualmente recursos gerenciados. Se um objeto contiver recursos gerenciados entre clientes, não haverá como o gerenciador de recursos se alistar automaticamente em uma transação quando o objeto for ativado em um determinado contexto.
O objeto em si deve lidar com a lógica de detetar a transação, desativar o alistamento automático do gerenciador de recursos e inscrever manualmente todos os recursos que ele detém. As etapas para fazer isso são específicas para o gerenciador de recursos que você está usando. Se você precisar fazer o alistamento manual, consulte a documentação do seu gerente de recursos.
Conforme descrito abaixo, os objetos podem ser agrupados com afinidade de transação enquanto uma transação está ativa e podem ser ativados com afinidade de transação se chamados por um cliente associado a essa transação. Antes de alocar recursos, deve primeiro verificar a afinidade de transação. Se o objeto tiver sido retirado do pool específico para essa transação, ele já fez trabalho nessa transação e alistou seus recursos.
Desativando o alistamento automático
O alistamento automático deve ser desativado depois que o recurso é adquirido, geralmente no construtor do objeto. Ou seja, você desativa o alistamento automático e, em seguida, se conecta.
A desativação do alistamento automático às vezes pode ser um procedimento sutil, especialmente no caso de provedores de acesso a dados em camadas. O alistamento automático às vezes é acoplado ao pool de conexões, como no ODBC, e às vezes não, como no OLE DB. Talvez seja necessário garantir que o alistamento automático esteja desativado em vários níveis de provedores.
Implementando IObjectControl
Os objetos agrupáveis que participam de transações devem monitorar o estado atual dos recursos que estão mantendo. Se o objeto detetar que está em um estado não reutilizável, por exemplo, se uma conexão for ruim, ele deverá retornar False para IObjectControl::CanBePooled. Isso terá o efeito de descartar a instância do objeto e comprometer irremediavelmente a transação atual.
Transaction-Specific Piscina
Um pool de objetos é geralmente homogéneo, e qualquer objeto armazenado no pool que não esteja em uso atualmente pode ser devolvido a qualquer cliente. A única exceção a essa regra é no caso de objetos transacionais, para os quais o pool de objetos é otimizado. Quando o cliente que solicita um objeto tem uma transação associada, o COM+ verificará o pool em busca de um objeto disponível que já esteja associado a essa transação. Se um objeto com afinidade de transação for encontrado, ele será devolvido ao cliente; caso contrário, um objeto do pool geral será retornado.
Dessa forma, subpools especiais são mantidos contendo objetos com afinidade para uma transação específica. Quando a transação é confirmada ou anulada, esses objetos são retornados ao pool geral sem afinidade de transação, prontos para serem usados por qualquer cliente.
Por esse motivo, quando seu componente inscreve manualmente seus recursos gerenciados em uma transação, ele deve primeiro verificar se eles já estão alistados. Em caso afirmativo, não há necessidade de se alistar.
Tópicos relacionados