Re: Obtendo um PropagationContext

[Danilo Conde <danconde@xxxxxxxxxx>]

Kleber, lembrei de um detalhe importante.

No meu primeiro email, disse que estava tentando pegar o Coordinator 
através do serviço de nomes do CORBA (fazendo resolve de 
CorbaTransactionService.COSNAMING_USERTX_NAME, o que na verdade é um 
TransactionFactoryExt.) Bom, no momento em que escrevi aquele momento já 
fazia algumas horas que estava na frente do computador, de modo que já 
estava bastante confuso... :-) De fato, eu até estava tentando fazer 
aquilo, mas agora estou pegando uma referência para o POA "Transactions" 
que é criado pelo startService() do CorbaTransactionService e mandando 
ele criar uma referência de Coordinator passando um object id com o 
LocalId  da transação. Assim, essa referência de Coordinator sabe de 
qual transação ele tem que criar um contexto quando chamo get_txcontext().

Danilo

Danilo Conde wrote:

> Olá Kleber,
>
>    Eu consegui propagar o contexto usando aquela estratégia, sim. 
> Também usei uma variável boolean evitar o loop infinito.
>    Quanto à exceção de ForeignTransaction, a implementação do método 
> importTransactionPropagationContext() tenta encontrar a transação com 
> o Id que você passou no contexto no servidor onde ele é chamado (no 
> servidor "alvo" - SA2), mas ela só existe no servidor que gerou o 
> contexto propagado (SA1), por isso a exceção está sendo lançada.
>    Eu alterei o método importTransactionPropagationContext() para que 
> ele crie uma TransactionImpl em SA2 quando receber um contexto que 
> possui um Coordinator. Essa transação fica "dependente" da transação 
> remota. Quando alguém chama enlistResource() nela, eu chamo 
> register_resource no Coordinator passando essa transação como um 
> org.omg.CosTransactions.Resource (fiz um adapter para a transação se 
> passar por Resource CORBA.)
>    Espero que isso ajude.
>
> Danilo
>
> PS: apenas esclarecendo: o que eu chamei de SA1 é o servidor que 
> contém um EJB que acessa um EJB em outro servidor, SA2.
>
> O que eu fiz, ao receber um contexto que possui uma transação e um 
> Coordinator, eu crio uma TransactionImpl em SA2 que
>
> Kleber Xavier wrote:
>
>> Oi Danilo,
>>
>> Estou seguindo uma estratégia semelhante a sua ( estratégia 2 ) para 
>> criar um PropagationContext, e também estou tendo problemas. Andei 
>> pesquisando por aí e parece que existe uma estratégia para evitar 
>> recursões infinitas em PortableInterceptors CORBA, então acho que 
>> esta estratégia não é estranha. Na própria documentação da Sun sobre 
>> CORBA IDL que vem junto com a documentação Javadoc do JDK eles 
>> mostram um exemplo de implementação baseada no uso de um slot no 
>> PICurrent para informar que a requisição é de saída e deve ser 
>> ignorado por outras chamadas ao mesmo interceptador. De qualquer 
>> forma ainda não consegui fazer esta implementação funcionar e estou 
>> utilizando uma solução meio "marreta" na qual criei um flag booleano 
>> que impede a recursão infinita. Não gostei muito desta solução, mas 
>> parece estar funcionando.
>>
>> Porém, mesmo resolvendo este problema, por alguma razão ainda estou 
>> tomando uma exceção de ForeignTransaction no segundo servidor. Acho 
>> que há algo errado com o método importTransactionPropagationContext().
>>
>> E você ? Conseguiu propagar o contexto transacional usando a 
>> estratégia 2 ?
>>
>> Um abraço,
>> Kleber
>>
>> Danilo Conde wrote:
>>
>>> Bom dia senhores,
>>>
>>>    Estou com um pouco de dificuldades para criar um 
>>> PropagationContext para passar nas requisições CORBA. Eu pensei em 
>>> duas formas de fazer isso:
>>>
>>> 1) Criar o PropagationContext na raça, preenchendo seus campos um 
>>> por um
>>> 2) Pegar um referência CORBA para o servente default 
>>> (TransactionServiceImpl) usando a inteface Coordinator e chamar o 
>>> método get_txcontext()
>>>
>>>    Comecei a testar a estratégia 2, por parecer ser mais prática. 
>>> Implementei no TxServerClientInterceptor um método que substitui o 
>>> getEmptyPropagationContext() e tenta pegar uma referência para o 
>>> Coordinator, procurando por "UserTransaction" 
>>> (CorbaTransactionService.COSNAMING_USERTX_NAME) no serviço de nomes 
>>> CORBA. Acontece que, ao chamar um método no no serviço de nomes 
>>> CORBA, ele passa no TxServerClientInterceptor >> send_request() 
>>> novamente, que faz passar no meu método novamente, fazendo um loop 
>>> infinito. Bom, aparentemente não é a coisa mais difícil do mundo 
>>> evitar esse loop infinito, mas no fim das contas eu achei que ficou 
>>> meio "estranha" essa minha estratégia. E para implementar a outra 
>>> estratégia, de qualquer forma eu vou precisar de uma referência pra 
>>> um coordenador, o que eu pretendia obter através do serviço de nomes 
>>> CORBA...
>>>
>>>    Alguém aí passou por esse problema ? Tem alguma sugestão ?
>>>    Ou fizeram isso de forma totalmente diferente ?
>>>    Tem algum outro jeito de obter um Coordinator ?
>>>
>>> Obrigado,
>>> Danilo
>>>  
>>>
>>
>>
>>
>
>
>