Olá, estava lendo um livro sobre banco de dados e ele cita “2 phase commit”. O que é isso?
Até.
É um protocolo para fazer commit distribuido.
Quando voce tem mais de 1 banco participando de uma transação é preciso utilizar ao menos o 2-phase commit para garantir que ela vai ocorrer corretamente.
e nao soh distribuido
muitos softwares usam isso internamente. inclusive o JBoss e todos bancos de dados.
a ideia eh super simples. Voce tem um casamento poligamico!
O padre (transaction coordinator) avisa cada um dos noivos (resources) de que eles se preparem para o casamento (commitment). Depois de avisados e preparados, ele sabe quem quer casa ou nao, e o padre para a segunda fase da cerimonia (por isso 2 phase!), na qual ele sai avisando, para cada participante, se deve haver casamento (commitment) ou divorcio (rollback), se houve um ou mais "nao"s.
1 curtida
ok, o termo correto seria ‘transação com mais de um participante’
Obrigado pelas resposta, galera. Paulo, eu acabei vendo um exemplo parecido com o seu no site da BEA:
http://edocs.bea.com/tuxedo/tux71/html/adtrn7.htm
Daí, acabei ficando com outras duvidas: o quanto 2 phase commit influência na performance de uma aplicação e como o custo cresce quando eu aumento a distribuição do sistema?
Até.
NOTA: Existe também o 2 [color=“red”]face [/color]commit, que é quando essa coisa não funciona.
No meu projeto trabalhamos com as duas variações, temos um banco Oracle sicronizado com um sistema Mainframe, quando rola tudo bem, “2 phase commit” na cabeça, quando resolve não sincronizar, ai entra a variação o “2 face commit”, fica todo mundo olhando uma para cara do outro. :roll: :roll: :roll:
Não é mole não… :flasingsmile:
Two-phase commit exige que um Transaction coordinator e pode ficar muito lento caso existam muitos participantes.
mas existem varias otimizacoes, como a de nao se importar com transacoes que sao read only.
louds, conhece alternativas?
mas existem varias otimizacoes, como a de nao se importar com transacoes que sao read only.
louds, conhece alternativas?[/quote]
Agora que vc falou isso e já que há um “transaction coordinator”, uma otimização seria limitar a replicação de tabelas que são heavily written, certo?!
Até.
Otimizaçõe diminuem o problema, porem não resolvem quando voce tem 100 nós ativamente participando de transações juntos.
Alternativas para oque? Coordenação de Transações Distribuidas? O único protocolo que conheco alem do 2-phase commit é o 3-phase commit, que não alivia em nada o problema.
Ate onde eu já ví, a melhor forma de contornar esse tipo de problema é planejar seu sistema para minimizar o número de envolvidos por transação, para isso nested transactions são ótimas.
O lugar onde voce pode ganhar bastante performance é no algoritmo de checkpointing distribuido, utilizado para formar uma linha de checkpoint.