Agrupando objetos transacionais
Os componentes transacionais que devem ser agrupados têm requisitos especiais.
Cadastrando recursos manualmente
Os objetos agrupáveis que participam de transações devem inscrever manualmente recursos gerenciados. Se um objeto mantiver 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 próprio objeto deve lidar com a lógica de detectar 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 gerenciador 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 inscrever recursos, você deve primeiro verificar a afinidade da transação. Se o objeto tiver sido retirado do pool específico para essa transação, ele já tiver feito trabalho nessa transação e alistado 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ê desabilita o alistamento automático e, em seguida, se conecta.
Desabilitar o alistamento automático às vezes pode ser um procedimento sutil, especialmente no caso de provedores de acesso a dados em camadas. Às vezes, o alistamento automático é 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 detectar que está em um estado não reutilizável — por exemplo, se uma conexão estiver incorreta — ele deverá retornar False para IObjectControl::CanBePooled. Isso terá o efeito de descartar a instância do objeto e condenar a transação atual.
Pools específicos de transações
Um pool de objetos é geralmente homogêneo, e qualquer objeto em pool que não esteja em uso no momento é bom para retornar 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 o componente inscreve manualmente seus recursos gerenciados em uma transação, ele deve primeiro verificar se eles já estão alistados. Se sim, não há necessidade de se alistar.
Tópicos relacionados