Re:Controle de transação entre duas bases distintas

[Spool]

[quote=sergiotaborda]
AO Transaction Manager importa um pepino se são máquinas ou bases diferentes.
O que vc faz é colocar o transaction manager a funcionar ( se usar um servidor JEE ele já está funcionando)
Abrea transação, le de X, grava em Y, le de Y grava em X e commita a transação. Simples assim.

Todo o trabalho de controle é feito pelo transaction manager.

Se vc não tem um transaction manager, a solução é arranjar um. O JTOM é uma boa tem até um tutorial de como instalalo no tomcat sem ser preciso servidor de aplicação, mas a melhor opção é realmente usar um servidor de aplicação que é para isso que eles servem.[/quote]

Qual a porcentagem de garantias que eu teria utilizando um Transaction Manager??

Porque, por exemplo, eu tenho uma pequena solução que contorna alguns possíveis erros. Isso me dá uma margem de aproximadamente 92% de garantias de que as transações (em ambos os lados) serão efetuadas.

8% de possibilidade de acontecer alguma coisa que não deveria, para mim é uma margem absurdamente grande.

Utilizando JTA ou o próprio JTOM (citado acima) eu conseguiria aumentar em quanto os meus 92% de garantia??

At.

[Spool]

?? 92% de garantia ? como vc chega nesse numero ?

Independentemente disso, 92% ou zero é a mesma coisa.
O Transaction Manager da JTA ( da qual o JTOM é uma implementação) lhe dá 100% garantia. Não poderia ser de outra forma já que as transações do JTA são ACID . A letra importante aqui é A (Atómica) que significa : ou faz tudo, ou não faz nada.
92% não faz nenhum sentido. Isso significaria que , para começo de conversa as suas transações não são atomicas. Se elas não são atomicas, mais vale nem usar transação. 92% significaria que faz quase tudo , mas o que não faz é suficiente para destruir o sistema. Nem que fosse 0.000…1%

Não faz sentido falar de porcentagem num ambiente ACID:

Atomico : ou tudo ou nada. Não ha meia alteração , nem 87% de alteração.
Consistente : o estado do sistema, antes, durante e depois da transação, independente se deu commit ou roolback é consistente, i.e. não se perde informação e não ha informação “lixo” sendo gerada.
Isolado: uma transação não interfere com a outra.
Duravél: se a transação altera o estado do sistema, o sistema permanece nesse estado.

Então, é exatamente isso o que eu preciso!
A porcentagem que eu citei, não corresponde a “gravar X %” dos dados, e sim da possibilidade de não acontecer nenhum problema de rede e/ou conexão com as bases.

Vou dar uma olhada no JTOM pra ver como funciona.

At.

[Spool]

[quote=clone_zealot]Em teoria, Two Phase Commit resolve exatamente o seu problema.
Se o seu processo realmente é batch, sem nenhum estresse com usuários alterando os dados durante o processo, Two Phase é o mais simples de implementar, e não precisa usar nenhum framework. Já está implementado no driver JDBC.
Dá uma pesquisa por XATransaction. O Oracle e o DB2 eu sei que suportam isso.
E é 100% de certeza que eles garantem ACID =D
A não ser que tiver bugs no banco, mas dai não há milagre que resolva a parada.
[edit]
Two Phase só faz o commit quando as duas bases dão o OK final.
[/edit][/quote]

Bom, uma das minhas bases é Oracle, a outra é SQLServer…
O processo é batch mesmo, sem intervenção de usuários.

O que eu preciso garantir eh de fato a consistência dos dois lados.
Vou dar uma pesquisada sobre Two Phase.

At.