1 / 22

Validação de Transações Móveis Danillo César e Silva Barbosa

Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática – CEEI Departamento de Sistemas e Computação Programa de Pós-Graduação em Informática Disciplina: Banco de Dados. Validação de Transações Móveis Danillo César e Silva Barbosa. Agenda. Introdução 2PC

nico
Download Presentation

Validação de Transações Móveis Danillo César e Silva Barbosa

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Universidade Federal de Campina GrandeCentro de Engenharia Elétrica e Informática – CEEIDepartamento de Sistemas e ComputaçãoPrograma de Pós-Graduação em InformáticaDisciplina: Banco de Dados Validação de Transações Móveis Danillo César e Silva Barbosa

  2. Agenda • Introdução • 2PC • Centralizado • Descentralizado • Linear • Validação em MDS • Ambiente Móvel • Protocolo de Validação

  3. Introdução • A execução distribuída de transações requer a colaboração dos nós para a validação. • A colaboração é iniciada e gerenciada por um nó coordenador. • O processo de validação tem duas fases • Checar a intenção de cada nó participante. • Coletar a intenção de cada participante e tomar a decisão de validar ou não a transação.

  4. Introdução • Esse processo é atômico, seguindo o ACP(Atomic Commitment Protocol). • Os ACPs mais comuns (em BDD): • 2PC • 3PC(Não implementado)

  5. Two Phase Commit Protocol • 2PC Centralizado • Um nó origina uma transação Ti assumindo o papel de coordenador e a fragmenta, distribuindo para o demais nós participantes. • O coordenador espera cada participante executar suas sub-transações e baseado no resultado de cada execução toma a decisão de validar ou não a transação Ti.

  6. Two Phase Commit Protocol • Descrição do protocolo(cinco passos) • Fragmentação • Fragmenta e distribui a transação. • Fase do voto(VR-Vote Request) • Pergunta aos participantes se pode ou não validar sua sub-transação. • O voto do participante • Vota e dependendo da resposta espera ou já aborta sua sub-transação. • A decisão do coordenador • Coleta as respostas, decide se valida e encaminha a decisão para os nodos. • A ação do participantes • Agem de acordo com a decisão do coordenador.

  7. Two Phase Commit Protocol • Falha do nó e ação de timeout • Falhas ocorridas nos participantes podem gerar atraso na decisão do coordenador, causando bloqueio. • Uma das formas evitar bloqueios é usar a ação de timeout. • Pode ocorrer um aborto imaturo da subtransação. • Adotar o cooperative termination protocol para que recupere a última mensagem emitida pelo coordenador.

  8. Two Phase Commit Protocol • 2PC Descentralizado • O coordenador minimiza a complexidade da mensagem. • Envia o seu voto junto com as mensagens VR enviadas para os nós. • Se o voto do coordenador for Não os participantes abortam as sub-transações e param.

  9. Two Phase Commit Protocol • 2PC Linear • A complexidade da mensagem é reduzida porque a coleta do votos é de forma serial. • Os nós estão dispostos linearmente.

  10. Two Phase Commit Protocol • Comparação entre os três tipos de 2PC com relação ao parâmetro números da mensagens.

  11. Validação em MDS Ambiente Móvel • O fator mobilidade afeta o processo de validação da transação. • Limitações: • MU perder a comunicação com a BS • Bateria limitada • Interferência • Comunicação limitada para canal wireless

  12. Validação em MDS • A transação em MDS é processada por nós DBS originada em um MU. • Em MDS o protocolo 2PC pode ser usado para validar transações mas sua performace não seria satisfatória.

  13. Protocolo de Validação em MDS • Com essas limitações em MDS o protocolo de validação de transações deve: • Usar o número mínimo de mensagens. • O MU e os DBS envolvidos devem ter capacidade de decisão independente. • Não deve gerar bloqueios.

  14. Protocolo de Validação em MDS • O parâmetro timeout pode ser usado para desenvolver um protocolo de validação para MDS. • Timeout pode identificar situação de sucesso. • A idéia é definir o timeout para a completa execução da ação e assumir que ao final desse timeout nenhuma falha ocorreu.

  15. Protocolo de Validação em MDS • O protocolo TCOT(Transaction Commit on Timeout) • Uma transação Ti é fragmentada e distribuida entre os DBS e o MU onde Ti foi originada. • Todos os nós envolvidos formam o Commit Set de Ti.

  16. Validação em MDS • TCOT tenta limitar o número de mensagens para não gerar overhead. • Assume que todos os membros validarão seus fragmentos dentro do timeout definido. • Se o coordenador não recebe mensagem de falha de algum membro dentro do período de timeout então ele valida a transação.

  17. Validação em MDS • Não é fácil encontrar o valor apropriado para o timeout pois depende do número de variáveis do sistema. • Geralmente é possível definir o valor de timeout que servirá bem para todos os casos. • Um valor impreciso não afetará a corretude do algoritmo mas sua perfomace será prejudicada.

  18. Validação em MDS • O TCOT usa dois tipos de timeout: Execution Timeout(Et) e Update Shipping Timeout(St). • Execution Timeout(Et): Define o valor dentro do qual um DBS completa a execução(mas não valida) do seu fragmento. • Shipping Timeout(St): Define o máximo de tempo para os dados serem transportados do MUH para o DBS.

  19. Validação em MDS • Pode-se dizer que Et ou “mensagem para validação” é suficiente para a tomada de decisão para fazer a validação? • Et identifica quando a execução do fragmento terminará e estará pronta para validar. • Ao final o coordenador assume que o DBS processou o fragmento, a qual não pode ser verdade.

  20. Validação em MDS • Por outro lado se usar só “mensagem para validação” • O coordenador pode nunca obter essa mensagem do DBS. • e pode esperar para sempre a decisão final de validar ou não a transação. • Portanto para se fazer a decisão final de validação de forma eficiente, ambos Ete “mensagem para validação” são necessários.

  21. Validação em MDS • TCOT é one phase commit. • A mensagem de atribuição da tarefa provê as informações necessárias para a validação. • No caso de aborto por parte de algumas sub-transações, mensagens extras são usadas. • Mas essas mensagens não geram um overhead considerável.

  22. Referências • Mobile Database Systems, John Wiley & Sons, 2006 Ralf Hartmut Guting. Moving Objects Databases, Morgan Kaufmann Publishers, 2005

More Related