TxManager do JBoss nao suporta criacao de nova Transacao pela mesmaThread, nem propagacao de Transacao por Threads diferentes

[Paulo Silveira <paulo@xxxxxxxxxxxx>]

Oi pessoal!!

Depois de muito trabalho, descobrimos nossos problemas. (sobre o 
PICurrent, ele ja eh ThreadLocal pelo que vimos depois, entao o erro nao 
estava ai...)

O TxManager.begin() rapidamente olha se ja nao existe uma 
TransacactionImpl associada a esta Thread.curretnThread() atraves da 
estrutura auxiliar ThreadInfo. Muito por acaso, se voce chamar duas 
vezes o seu TransactionFactoryExt.create_context(), a MESMA Thread vai 
atender o seu request (descobrimos isso imprimindo o nome da Thread na 
tela).

Isso acontece porque o JBoss usa internamente um Pool de Thread (ele 
nomeia de RequestProcessors) para atender todas as requisicoes 
(engracado que essa eh uma requisicao Corba pura, talvez esse pooling 
seja do jacorb), e ai ele aloca a mesma Thread para atender o pedido, 
devido ao baixo processamento do servidor.

Isso faz com que uma excecao seja lancada! Pois ele acha que voce esta 
tentando fazer nested transaction, que nem o JBoss, nem a especificacao 
j2ee pede.

Entao, a gente tentou fazer uma pequena modificacao. Quando o nosso 
MBean, que eh o nosso TransactionFactoryExt, pede o begin pro TxManager, 
a gente nao faz isso na mesma Thread, a gente cria uma nova Thread soh 
pra dar begin() e getTransaction(). (aka gambiarra).

Com isso, funcionou ele dar um novo begin! Porem, na hora do commit ou 
rollback, internamente o TxManager locka a Thread que fez o request, mas 
ela ja morreu!!! Ela foi usada soh para criar a Thread, e ai entra num 
deadlock o servidor inteiro, pelo que a gente pode perceber.

Isso tudo acontece porque a especificacao diz que uma transacao eh 
propagada pela mesma Thread, e o JBoss TxManager nao foi feito esperando 
que um dia a gente fosse fazer essa aplicacao. Ah! Tambem achamos que 
dessa maneira nao da para fazer o sistema de transacoes distribuidas 
explicado na sala de aula, pelo mesmo motivo do pool de 
"RequestProcessors" e do TxManager levar em consideracao a associacao 
1:1 de Transaction:Thread.

Em outras palavras, nosso sar/lib eh single thread do lado do servidor, 
isto eh, single client! :)

Alguem conseguiu contornar isso?

--
paulo silveira