220 likes | 308 Vues
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
E N D
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
Agenda • Introdução • 2PC • Centralizado • Descentralizado • Linear • Validação em MDS • Ambiente Móvel • Protocolo de Validação
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.
Introdução • Esse processo é atômico, seguindo o ACP(Atomic Commitment Protocol). • Os ACPs mais comuns (em BDD): • 2PC • 3PC(Não implementado)
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.
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.
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.
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.
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.
Two Phase Commit Protocol • Comparação entre os três tipos de 2PC com relação ao parâmetro números da mensagens.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Referências • Mobile Database Systems, John Wiley & Sons, 2006 Ralf Hartmut Guting. Moving Objects Databases, Morgan Kaufmann Publishers, 2005