Re: Recuperaçãoo de quedas de resources

[Livio Baldini Soares <livio@ime.usp.br>]

  Fala Speicys!


Roberto Speicys Cardoso writes:

[...]

>   Ops.. Acho que tenho um problema. Tentei começar a implementar a
> recuperação de falhas no construtor do TxManager. Seguindo a minha
> estratégia, tentei pegar no JNDI todas as referências para bancos de dados
> configuradas no JBoss. 
>
>   Infelizmente, no momento da primeira instanciação do TxManager, os
> bancos de dados ainda não foram configurados, e não existe referência para
> eles no JNDI ainda. 

  Tem toda  razão! Eu  também estou quebrando  a cabeça com  isso.  Na
verdade, ainda  não conseguimos testar  realmente nada do  meu código,
pois estamos tendo um trabalho danado para conseguir levantar o Oracle
(versão demo do site) :-(

  Estamos  só  programando  "de  cabeça"...  o  que  é  horrível  pois
raramente dá certo.

>   Eu não sei aonde poderia ser feito o ponto de entrada para o processo de
> recovery. O ideal seria colocar o recovery depois de ter sido feita a
> inicialização do JBoss, mas antes de começar o deployment. Entretanto não
> tenho a menor idéia de onde fica este ponto do código nas classes do
> JBoss. Não sei se utilizando algum ConnectionFactory existiria uma forma
> de contornar este problema. 

  O  problema de  se fazer  isso é  que o  código ficará  acoplado com
outras  parte do  JBoss. Isto  é,  o gerenciamento  de transações  não
ficará  como um  módulo auto-contido  que o  JBoss pode  usar  só para
chamar serviços.  E isso é bem  ruim. Por outro lado,  não estou vendo
uma solução para esse problema. 

  Seria interessante  descobrir como outros  TxManagers resolvem tanto
esse problema,  quanto o problema que  apontei no outro  e-mail de que
não  existe  mecanimos  (aparentemente)   para  que  os  resources  se
comuniquem com  o seu  subordinado para descobrir  o resultado  de uma
transação em caso de queda.

>   A minha solução, apesar de errada, é colocar o recovery dentro do begin
> do TxManager. Ainda assim, o begin é chamado algumas vezes sem que todas
> as referências aos bancos tenham sido criadas. Então meu processo de
> recovery funcionaria assim: cada vez que uma nova transação vai começar,
> eu vejo os bancos de dados configurados, faço recovery deles, e marco como
> já recuperados. Da próxima vez que for iniciada uma transação, eu vejo se
> existe alguma referência a algum banco não recuperado, e repito o
> processo. Isso é errado, porque depende de que seja feita pelo menos uma
> nova transação para que um dado banco seja recuperado, o que não faz muito
> sentido.. Se alguém tiver alguma idéia de onde colocar o ponto de entrada
> do recovery, ela será bem vinda.

  Bom,  até que não  é tão  ruim assim  sua solução.   Inclusive, você
poderia fazer  _sempre_ a checagem  de necessidade de  recuperação (ao
invés de  marcar como recuperado).  Dessa forma  resolveria o problema
que eu  cisto acima. Isto é, quando  um resource cai e  levanta (sem o
JBoss ficar ciente de nada,  é claro), e posteriormente é executado um
outro begin, você pode pegar todos os XAResources e dar um recover() e
verificar se existe alguma transação na lista devolvida que já deveria
ter sido completada, caso sim, então tome as metidas cabíveis. 

  Bom... isso tá ficando uma  gambi depois da outra, e estamos fugindo
muito  da fase  de  recuração do  protocolo  original.  Essa  proposta
estaria mudando o paradigma de que os subordinados devem fazer "pull",
para um que o coordenador sempre  faz "push". O que implica numa perda
razoável  na  complexidade  do   algoritmo  (temos  que  ficar  sempre
verificando se tem alguém subordinado "inconsistente"). 

  _Mas_ por mais que eu procure, não estou achando exemplos/código que
de fato implementam o serviço de transações "direitinho". 
  
  Ao menos que a recuperação  quando subordinados caem não seja escopo
desse  trabalho  em  particular,  como  você  havia  falado  no  outro
e-mail. Aí deixaria o algoritmo bem mais limpo mesmo.

  Será que  estou viajando? Acho  que seria interessante se  o pessoal
discutisse essas questões (ou  pelo menos se estiver falando besteira,
me mostrem alguma referência, ou qualquer coisa...) 

   Falous!

--  
  Livio <livio@ime.usp.br>