Re: Testes para voces fazerem com seu EP2 que nao passvaa pra gente....

[Flávia Rainone <flaviarnn@xxxxxxxxx>]

É mesmo. Não tínhamos pensado nisso...

Bom, eu acho que a solução seria colocar o PropagationContext no ThreadLocal (acho que o Reverbel chegou a falar isso em classe, mas não tenho certeza, faz tempo). Sempre que o CosTransactions:Current tiver que chamar um método de um Control, de um Terminator ou de um Coordinator, ele colocaria o PropagationContext no PICurrent, para que o Interceptor consiga pegar esse valor. Após executar a chamada, o Current removeria o valor que ele colocou no PICurrent.

Talvez, fosse bom que o CosTransactions:Current tivesse os métodos protegidos a acesso concorrente (synchronized), para que o PICurrent não tivesse acesso concorrente. Vou tentar fazer isso no meu ep, apesar de já ter entregue.

Espero que funcione.

 

Flávia

Paulo Silveira <paulo@paulo.com.br> wrote:

> Oi pessoal!
>
> Falei besteira. Essa solucao nao funciona para multiplas threads... A 
> gente ainda tem problema nisso.
>
> O EP funciona perfeitamente, mas apenas para clientes single threaded.
>
> O problema eh o seguinte. A gente registra o CosTransactions.Current 
> como sendo o nosso TransactionCurrent. No begin, a gente coloca dentro 
> do slot do PICurrent o propagationContext. No commit e rollback, a gente 
> pegat o propagationContext do slot do PICurrent, e chama o 
> terminator.commit/rollback.
>
> Soh que parece que esse PICurrent tambem eh uma unica instancia. 
> Independente de como a gente pega ele, seja numa Thread ou em outra, ele 
> devolve a _mesma_ referencia. Isso poderia estar ok, se internamente ele 
> usasse ujma politica ThreadLocal para guardar os slots. Mas pelo o que a 
> gente viu, ele nao usa....
>
> Sugestoes? Alguem mais testou
>  o programa para cliente multithreaded?
>
> Paulo
>
> Paulo Silveira wrote:
>
> > Oi pessoal.
> > 
> > Durante a execucao de uma transacao do cliente, antes de comitar ou dar 
> > rollback, voce cria uma nova Thread, e pede para ele fazer outra 
> > transacao nesse meio tempo.
> > 
> > Para voce ter certeza que a thread que voce criou vai executar 
> > inteirinha antes de voce continuar, voce faz:
> > 
> > TestaThreadDeCliente thread = new TestaThreadDeCliente();
> > thread.start();
> > thread.join();
> > 
> > O join vai esperar ela morrer.
> > 
> > Aqui a gente tinha um problema. Quando a gente dava begin, a gente tinha 
> > uma referencia para um TransactionCurrent que tinha sido registrado no 
> > initializer. Mas ele era uma instancia unica, entao todo mundo numa 
> > mesma vm/classloader tava pegando o mesmo cara, e a transacao era a mesma.
> > 
> > Ai o Alex viu que eu tinha feito a
>  besteira de guardar o 
> > PropagationContext tambem como variavei de instancia do 
> > TransactionCurrent, e o que a gente fez entao foi sempre ver isso no 
> > slot do PICurrent, que se responsabiliza por fazer a politicagem de 
> > ThreadLocal.
> > 
> > 
> > Alguem mais fez assim?
> > 
> > Falou
> > 
> > 
> > 
> >

---

Yahoo! Mail - 6MB, anti-spam e antivírus gratuito. Crie sua conta agora!