Modelos de Transações para Ambiente de Computação Móvel Maria Beatriz F. Toledo Tarcísio da Rocha Instituto de Computação Universidade Estadual de Campinas

Modelos de Transações para Ambiente de Computação

Móvel

Maria Beatriz F. ToledoTarcísio da Rocha

Instituto de Computação

Universidade Estadual de Campinas

Sumário

1. Introdução2. Transações Tradicionais3. Report e Co-Transactions4. Coda-IOT5. Promotion6. Transações Fracas e Fortes7. MobileTrans8. AMT9. Comparação e Conclusões

Introdução

1. Consistência de dados para aplicações distribuídas – ambiente: máquinas fixas, redes

tradicionais– solução: transações que oferecem

transparência de concorrência e falhas

Introdução

2. Consistência de dados para aplicações distribuídas– ambiente: máquinas móveis, redes

sem fio– problemas a enfrentar: restrições do

dispositivo móvel, do meio de comunicação

Variações na largura de banda.- Conexão Forte

Rede fixaConexãocom fio

Introdução Problemas a enfrentar

Variações na largura de banda.- Conexão Fraca

Rede fixaConexão com redesem fio


Variações na largura de banda.- Desconexão

Rede fixa

Desconectado


Erros na transmissão Alto custo da comunicação

Rede fixaConexãosem fio


Desconexões freqüentes

DesconectadoRede fixa


Escassez de energia do dispositivo móvel. Menor poder computacional


Segurança mais vulnerável.

Rede fixa

Intruso


As considerações feitas em relação ao ambiente de rede tradicional raramente são válidas ou apropriadas para o ambiente computacional móvel.


1. autonomia da máquina móvel: capacidade de adaptação a variações no ambiente– minimizar comunicação

• mecanismos assíncronos• compressão de dados• réplicas em cache local

2. capacidade de adaptação a variações no ambiente– permitir participação da aplicação na adaptação

(melhor desempenho e flexibilidade)

IntroduçãoObjetivos

IntroduçãoObjetivos

3. revisar propriedades e mecanismos de transações– controle de concorrência baseado em trancas

• bloqueia dados por muito tempo se transação desconectada

– controle de concorrência otimista• número de conflitos aumenta com desconexões

longas

– critérios semânticos• para diminuir conflitos• para facilitar reintegração

Transações Tradicionais

• Origem– aplicações comerciais e financeiras

que utilizam BDs

• Características das aplicações– curta duração– tipos de dados restritos– tipos de operações restritos

Transações Tradicionais

• Problemas que podem ocorrer durante execução:– compartilhamento de dados por aplicações

concorrentes

– ocorrência de falhas que interrompem a execução de aplicações

Transações Tradicionais Objetivos

• oferecer mecanismos para

– controle de concorrência sobre dados

compartilhados

– recuperação de dados

• simplificar o desenvolvimento de

aplicações

• assegurar a obtenção de resultados

corretos

Transações Tradicionais Operações

• operações sobre itens de dado: read, write• operações de controle: begin, commit, abort

(estado consistente 1)

begin

reads/writes

commit



begin

reads/writes

abort


Transações TradicionaisExecução com concorrência


begin

reads/writes

begin

reads/writes

commit

reads/writes

commit


Transação 1

Transação 2

Transações TradicionaisExecução com falha


begin

reads/writes

...


falha


begin

reads/writes

commit

...


falha

Transações Tradicionais Propriedades

• atomicidade

• consistência

• isolamento

• durabilidade

Transações TradicionaisControle de Concorrência

• transações seqüenciais – garantia de consistência

– compromete desempenho

• transações concorrentes– entrelaçamento de operações provoca

interferência

– melhora desempenho


• Tipos de interferência - exemplos– escrita perdida (lost update)

r1(x) w1(x) w2(x) a1

– leitura inconsistente (dirty read)r1(x) w1(x) r2(x) a1


• Objetivos– evitar interferências entre transações

concorrentes– produzir históricos corretos

(consistentes)• histórico seqüencial• histórico serializável

– concorrente– equivalente a um histórico sequencial


• Equivalência– pares de operações conflitantes aparecem

na mesma ordem• r1(x) w2(x), w1(x) r2(x), w1(x) w2(x)

– exemplo• histórico seqüencialH1: r1(x) w1(x) r2(x) w2(y) T1<T2H2: r2(x) w2(y) r1(x) w1(x) T2<T1• histórico serializávelH3: r1(x) r2(x) w2(y) w1(x) T2<T1

Transações TradicionaisMecanismo para Controle de Concorrência

• escalona operações de forma a produzir históricos corretos

• após receber uma operação pode:– executá-la imediatamente

– atrasá-la bloqueando transação

– rejeitá-la abortando transação

Transações TradicionaisTrancas (locks)

• tranca é solicitada antes de qualquer operação em um dos modos:– compartilhado para read– exclusivo para write

• tranca é concedida se compatível com trancas já existentes

• se incompatível transação é bloqueada• trancas são liberadas no final da

transação• problema principal: deadlocks

Transações TradicionaisOrdenação por Timestamp

• cada transação tem um timestamp• cada operação deve ser acompanhada

do TS da transação• cada item de dado tem associado:

• TS de leitura - RTS• TS de escrita - WTS

• Histórico resultante– equivale ao seqüencial ordenado por ordem

de TS

Transações TradicionaisOrdenação por Timestamp

• OperaçõesTS é o timestamp da operação– leitura

se TS < WTS rejeitasenão executa (RTS= max(RTS, TS)

– escritase TS < RTS ou TS < WTS rejeitasenão executa (WTS=TS)

• Problema principal: número de cancelamentos

Transações TradicionaisCertificação (Método Otimista)

• uma transação tem 3 fases:– fase de execução

• operações de leitura são executadas sem restrições• operações de escrita são executadas sobre área de

trabalho da transação

– fase de validação• testa conflitos que causem inconsistência

– fase de atualização• se passa na validação, efetiva atualizações

• problemas: números de cancelamentos

Transações TradicionaisRecuperação de Falhas

• Tipos de falha– falhas de transação– falhas de sistema

• Estados armazenados– estado do sistema antes de a transação

iniciar(necessário quando transação é abortada)

– estado contendo as atualizações da transação

(necessário se transação termina com sucesso)

Transações TradicionaisRecuperação de Falhas

• estrutura utilizada - log– para guardar histórico da execução das

transações. Inclui:• informação para desfazer e refazer operações

executadas

• informação sobre o estado das transações

• mecanismo de recuperação– operações são desfeitas em caso de falha

– operações são refeitas para transações que terminarem com sucesso

Report e Co-Transactions Chrysanthis

• Objetivos– permitir troca de resultados parciais

entre transações– permitir distribuição da computação

entre máquinas fixas e móveis– flexibilizar atomicidade

Report e Co-Transactions Modelo

• Uma transação móvel é um conjunto de subtransações que podem ser:

1. subtransações atômicas: • compensáveis: para as quais podem ser definidas

transações compensatórias• compensatórias: que desfazem efeitos de

subtransações compensáveis

2. subtransações não compensáveis: resultados são delegados para transação móvel.

Report e Co-Transactions Modelo

3. subtransações report: delega resultados

parciais com transação móvel.

4. subtransações co-transactions: report com

comportamento de co-rotina.

Report e Co-Transactions Propriedades

• isolamento relaxado:– subtransações compensáveis tornam

resultados visíveis no final

– subtransações report compartilham resultados parciais com transação móvel

• atomicidade: efetivação de resultados parciais no final de cada subtransação compensável.

Report e Co-Transactions Propriedades

• vitais/não vitais.

• mobilidade:– transação móvel executa na máquina móvel

– report e co-transactions executam em máquinas fixas mas podem se mover para acompanhar máquina móvel

Coda-IOT Lu e Satynarayanan

• Objetivos– permitir execução de transações em

máquinas móveis conectadas ou desconectadas

– evitar o bloqueio de arquivos utilizando controle de concorrência otimista

Coda-IOT Origem

Sistema de arquivos Coda:• interface Unix• replicação de arquivos

– cópia de primeira classe em servidores (máquinas fixas)

– cópia de segunda classe na máquina móvel

• controle de concorrência otimista– escritas no cliente– validação no servidor

Coda-IOT Propriedades

– atomicidade (por volume)– isolamento– durabilidade condicional– consistência baseada em

seriabilidade

Coda-IOT

• controle de concorrência local baseado em trancas

• manutenção de log local• no final da transação ou no momento da

reconexão, log é enviado para servidores• servidores utilizam log para validar

transações• estados dos arquivos são propagados do

cliente para servidor se transação for válida

Coda-IOT Estados das Transações

efetivada em resolução

resolvida

em execução pendente início fim com

partição

sucesso na validação

resolução

fim sem partição fracasso na

validação

Transação Desconectada

TransaçãoConectada

Coda-IOTMudança de Estados

• quando transação é iniciada passa para estado em execução

• quando termina passa para:– efetivada: se mantém conexões. Estado é

imediatamente propagado.

– pendente: se perde conexões. Libera dados para transações locais criando dependências.

Coda-IOTMudança de Estados

• na reconexão: determina ordem de

transações pendentes e envia log de uma

em uma.

– Se válida passa para estado efetivada.

– Se inválida passa para estado em resolução.

• quando termina resolução de conflito,

transação passa para estado resolvida.

Coda-IOTResolução de Conflitos

• re-execução automática da transação

• cancelamento automático

• execução de programa para resolver

conflitos

• reparo manual pelo usuário

Promotion Walborn e Chrysanthis

• Objetivos– evitar bloqueio utilizando controle de

concorrência semântico

– aumentar autonomia através de replicação local

• Aspectos principais– encapsulamento de dados em compacts

– transações com vários níveis de consistência

Promotion Estrutura de Compacts

• dados

• métodos específicos

• informação sobre estado

• regras de consistência

• obrigações

• métodos para gerenciamento do compact– inquire, commit, abort

ProMotionCompact - Lease

• métodos específicos– read, modify

• dado• regras de consistência: não tem• obrigações

– prazo

• estado– data da última atualização

ProMotionCompact - Objetos Fragmentáveis I

• Conceito– pode ser dividido em partições menores– partições podem ser armazenadas na

máquina móvel

• Objetivos– fornecer granularidade fina de cache e

controle de concorrência– facilitar integração depois de reconexão– permitir efetivação local de transações

ProMotionCompact - Objetos Fragmentáveis II

• Operações

– split

– merge

• Tipos de fragmentos

– lógicos (escrow)

– físicos (pilhas, filas, conjuntos)

ProMotionCompact - Escrow

• métodos específicos– increase, decrease

• dado (do tipo inteiro)• regras de consistência

– valor máximo e mínimo

• obrigações– prazo

• estado– escrow journal

ProMotionCompact - Pilha I

• operações: push, pop

• itens inseridos por uma transação ficam adjacentes na pilha

• fragmentos: porção contendo dados interdependentes

• fisicamente fragmentáveis

• reordenáveis

ProMotionCompact - Pilha II

CT2 BT2 AT2 CT1 BT1 AT1 Si

• pilha é fragmentada em:

CT1 BT1 AT1 Si

para MH2para MH1

CT2 BT2 AT2

AT2

• T3 em MH1 faz 2 pop’s e termina• T4 em MH2 faz 2 pop’s, push e termina

AT4 AT1

ProMotionCompact - Pilha III

• após merge:

AT4 AT1 SiAT2

que equivale T1 T4 T2 T3

AT2AT4 AT1

• ou:

Si

que equivale T2 T3 T1 T4

Promotion Transações

• modo: conectado, desconectado– na reconexão, prazos de expiração de compacts

são verificados

• níveis de consistência: 0 (sem garantia),..., 8 (serializável), 9 (seqüencial)

• cada método tem nível e modo de acessso (read/write)

• cada transação tem nível para read e write

Promotion Transações

• cada operação só pode ser executada se seu nível for nível da transação

• transação termina com sucesso se dados lidos têm nível nível dados modificados

• Objetivos: – lidar com desconexões– oferecer apoio à adaptação a largura de

banda

• Idéias básicas:– agrupamento de dados– consistência dentro do agrupamento ou entre

agrupamento– novas operações weak read/weak write– dois tipos de transações: weak e strict

Transações Fracas/FortesPitoura e Barghava

Transações Fracas/FortesAgrupamentos

• agrupamento de dados relacionados (por localização ou semântica)

• reconfiguração dinâmica de agrupamentos (dispositivo móvel pode sair de agrupamento devido a desconexões ou deslocamento de células)

• replicação no cache do dispositivo móvel (pode se tornar um agrupamento se desconectado)

Transações Fracas/FortesConsistência

• dados dentro de um agrupamento são consistentes

• dados em agrupamentos diferentes podem apresentar um certo grau de inconsistência

• grau de consistência pode variar de acordo com disponibilidade de banda entre agrupamentos (aplicação pode se adaptar)

Transações Fracas/FortesOperações Fracas/Fortes

• weak read/weak write operam sobre dados dentro de um agrupamento

• strict read/strict write operam sobre dados consistentes (read e write padrão)

• strict read só lê dados escritos por strict write

Transações Fracas/FortesEfetivação de Transações

• weak transaction: realiza weak reads e weak writes. – Operam sobre dados locais ao agrupamento

da transação. – Duas efetivações: local ao agrupamento

(dados visíveis para outras weak transactions) e global na reintegração do agrupamento.

• strict transaction: realiza strict reads e strict writes. Efetivação global.

MobileTransSantos, Veiga, Ferreira

• Objetivos– oferecer apoio à adaptação através de

políticas para busca de objetos, armazenamento local de objetos, delegação de objetos, relaxamento de consistência e atomicidade, tratamento de falhas

– permitir extensão com relação a outros atributos não previstos inicialmente

MobileTransConsistência

• Atributo objeto– valores: required, replica, dispensable

• Atributo grau da transação– valores: high, medium, low– high: objetos devem ser buscados de nó seguro.– medium: objetos com atributo de consistência

required são buscados de nó seguro. Os outros podem vir de cache local ou de outros nós.

– low: required de nó seguro, replica de qualquer nó, dispensable não precisam ser alcançados.

MobileTrans Busca de objetos

• Atributo modo– valores: prefetch, ondemand

• Atributo objeto– valores: random, node, randset

MobileTrans Delegação

• o papel de coordenador pode ser

delegado para outros nós

– nó específico

– aleatório dentro de um conjunto

– aleatório

MobileTrans Atomicidade

• Atributo objeto– valores: mandatory, tentative

• Atributo grau– valores: high, low– no grau high todos os objetos (cópia

principal) devem ser atualizados– no grau low só objetos mandatory precisam

ser atualizados. Objetos com atributo tentative podem ser atualizados localmente ou descartadas.

MobileTrans Armazenamento Local

• indica se objeto deve ser armazenado em cache local

MobileTrans Tratamento de Falha

• Atributos: consistência, busca, delegação, atomicidade, usuário

• valores: abort, retry suspend

Adaptable Mobile Transactions Alvarado et al.

• Objetivos– oferecer apoio à adaptação através da

definição de várias alternativas de execução

• Idéia básica– uma transação adaptável consiste de várias

alternativas (podem ser semanticamente equivalentes)

– a cada alternativa está associado um descritor de ambiente que descreve o estado necessário para executar essa alternativa

Adaptable Mobile Transactions Descritor de Ambiente

• rede– estado da conexão: connected, disconnected– largura de banda: high, medium, low– custo de comunicação: free, cheap, expensive

• dispositivo móvel– disponibilidade de bateria: full, half, low– disponibilidade de cache: full, half, low– disponibilidade de memória persistente: full, half,

low– capacidade de processamento: high, medium, low– tempo estimado de conexão: hh:mm:ss

Adaptable Mobile Transactions Definição

AMT = (T, CT, <EAk>)• T é o conjunto de transações componentes• CT é o conjunto de transações de compensação

• EAk para k 1, é a lista de alternativas onde EAk tem prioridade sobre EAk+1

• EAk = (EDk, EPk) , uma alternativa EAk tem um plano de execução EPk se o ambiente satifaz o descritor associado EDk

– EPk = {(Tki,H)}, Tki T, um plano Epk é um conjunto de pares transação componente e host para sua execução

Adaptable Mobile Transactions Propriedades

• atomicidade semânticaou todas as transações numa alternativa

terminam com sucesso ou todas são abortadas (ou compensadas)

• isolamentotransações que podem ser compensadas

liberam resultados no finaltransações que não podem ser compensadas

esperam efetivação global para liberar resultados

Comparação

MODELO PROPRIEDADES AUTONOMIA

ADAPTAÇÃO

Report I, A

IOT D Réplica local

PROMOTION

C, D Réplica local, itens frag.

Trans. Fracas/Fortes

C, D Réplica local

Níveis de consistência

AMT I, A Alternativas

MobileTrans C, A Reconfiguração

Conclusões

• revisão de propriedades e mecanismos do modelo tradicional de transações

• conhecimento sobre ambiente para configurar transação

• notificação sobre variações para reconfigurar transação e permitir melhor adaptação

Documents

Modelos de Transações para Ambiente de Computação Móvel Maria Beatriz F. Toledo Tarcísio da Rocha Instituto de Computação Universidade Estadual de Campinas