gestão de dados partilhados em ambientes de computação móvel
gestão de dados partilhados em ambientes de computação móvel gestão de dados partilhados em ambientes de computação móvel
128 CAPÍTULO 8. RESERVAS tipo tabela coluna condição valor informação escrow trains available train=’London-Paris 10:00’ 2 ≥ 0 value-use trains price AND 95.00 - value-change tickets * day=’18-FEB-2002’ (4A, f alse,...) - value-change tickets * (4B, f alse,...) - Tabela 8.3: Reservas obtidas pelo garantir reservas de bilhetes de comboio (identificador, ligação e data de expiração omitidos). tipo tabela coluna condição valor value-lock trainsids * true todos os registos value-use trains price train=23 AND day=’18-FEB-2002’ 95.00 value-change tickets * train=23 AND day=’18-FEB-2002’ (4A, f alse,...) value-change tickets * train=23 AND day=’18-FEB-2002’ (4B, f alse,...) Tabela 8.4: Reservas obtidas pelo garantir reservas de bilhetes de comboio: segunda alternativa (identi- ficador, ligação, informação e data de expiração omitidos). nome do passageiro associada a esse lugar (linhas 10-11). Vamos assumir que o cliente obteve reservas sobre dois lugares do comboio: as reservas respectivas são apresentadas na tabela 8.3. O processamento da transacção móvel prossegue de forma similar ao exemplo anterior até ser necessário obter o identificador do lugar a usar. A instrução select (linhas 8-9), que obtém o identificador do lugar, devolve um dos lugares reservados porque as instruções de leitura devolvem preferencialmente valores reservados. Neste caso, poder-se-ia obter, por exemplo, o lugar “4A”. A instrução update (linhas 10-11) actualiza a informação relativa ao lugar “4A” com o nome do passageiro e o preço do bilhete. Estas instruções são garantidas pela reserva value-change que o cliente detém sobre o registo que mantém a informação do lugar “4A”. Quando a transacção móvel é executada no servidor, o sistema garante que a instrução select devolve o mesmo registo, i.e., o registo relativo ao lugar “4A”. Assim, o resultado da transacção no cliente é o nível full de reservation commit (todas as instruções são garantidas). Se as reservas value-change não estivessem disponíveis, seria impossível garantir as instruções de leitura e escrita relacionadas com o lugar (linhas 8–11). O resultado da instrução select seria obtido a partir da versão provisória dos dados. Assim, o resultado da execução local da transacção seria o nível pre-condition de reservation commit. Para esta transacção, este resultado significa que é possível garantir a disponibilidade e preço do lugar, mas é impossível garantir o lugar que será atribuído ao passageiro. Na figura 8.3 apresenta-se uma versão alternativa para reservar um lugar num comboio. Neste exem- plo, a base de dados mantém uma tabela que associa o nome do comboio com o seu identificador (um inteiro). Adicionalmente, não existe informação sobre o número de lugares disponíveis: este valor é obtido contando o número de lugares não ocupados. Na tabela 8.4 apresentam-se as reservas obtidas para garantir dois lugares. Relativamente à versão
8.5. EXEMPLOS 129 1 ------ COMPRA 1 BILHETE: comboio = "London-Paris 10:00"; dia = ’18-FEB-2002’; preço máximo = 100.00 2 BEGIN 3 SELECT id INTO train_id FROM trainsIds WHERE name = ’London-Paris 10:00’; 4 SELECT price INTO tkt_price FROM trains WHERE train = train_id AND day=’18-FEB-2002’; 5 SELECT count(*) INTO tkt_avail FROM tickets WHERE train = train_id AND day=’18-FEB-2002’ AND used=FALSE; 6 IF tkt_price = 1 THEN --Verifica disponibilidade de lugar e se preço é aceitável 7 -- Selecciona e reserva um lugar específico para o comprador 8 SELECT seat INTO tkt_seat FROM tickets 9 WHERE train = train_id AND day = ’18-FEB-2002’ AND used = FALSE; 10 UPDATE tickets SET used = TRUE, passenger = ’Mr. John Smith’ 11 WHERE train = train_id AND day = ’18-FEB-2002’ AND seat = tkt_seat; 12 NOTIFY( ’SMTP’, ’sal-07@thingco.pt’, ’Bilhete reservado...’); 13 COMMIT (tkt_seat,tkt_price); -- Conclui a transacção e devolve a informação 14 END IF; -- sobre o lugar reservado 15 ROLLBACK -1; 16 ON ROLLBACK NOTIFY( ’SMS’, ’351927435456’, ’Impossível adquirir bilhete ...’); 17 END; Figura 8.3: Transacção móvel para reservar um bilhete de comboio num sistema de reserva de bilhetes: segunda alternativa (o bloco de declaração de variáveis é omitido). tipo tabela coluna condição valor slot datebook * day=’17-FEB-2002’ AND hour ≥ 8 AND todos os registos que hour ≤ 13 AND name = ’J. Smith’ satisfazem a condição Tabela 8.5: Reservas obtidas sobre uma agenda partilhada para garantir novas marcações (identificador, ligação, informação e data de expiração omitidos). anterior, obtém-se adicionalmente a reserva value-lock que permite garantir a conversão efectuada entre o nome do comboio e o seu identificador. Esta conversão é efectuada no início da transacção móvel (linha 3). Como o valor obtido é garantido pela reserva value-lock, a utilização do identificador do comboio não introduz nenhum problema para a possibilidade de garantir a transacção. A segunda diferença em relação à versão anterior consiste na inexistência de um elemento de dados com o número de lugares disponíveis (sobre o qual se obtinha uma reserva escrow). Neste caso, a tran- sacção móvel conta o número de lugares não ocupados (linha 5). As reservas value-change permitem garantir que, aquando da execução da transacção móvel no servidor, existem, pelo menos, dois lugares disponíveis (uma garantia semelhante à obtida anteriormente pela reserva escrow). Assim, é possível ga- rantir o resultado da condição da instrução if (linha 7). O processamento da transacção móvel prossegue de forma idêntica à versão anterior, permitindo obter como resultado o nível full de reservation commit. Agenda partilhada Neste exemplo, supõe-se que existe uma agenda que mantém o conjunto de mar- cações de demonstrações a efectuar pelos vendedores de uma empresa. Esta agenda pode ser modificado por vários utilizadores (por exemplo, os vendedores e as secretárias da empresa). Na figura 8.4 apresenta-se uma operação típica deste tipo de aplicação: a introdução de uma nova marcação. Supõe-se adicionalmente que o vendedor obteve uma reserva slot que lhe permite introduzir marcações em seu nome para a manhã do dia 17 de Fevereiro, como descrito na tabela 8.5.
- Page 95 and 96: 5.2. AGENDA PARTILHADA 77 Figura 5.
- Page 97 and 98: 5.2. AGENDA PARTILHADA 79 de awaren
- Page 99 and 100: Capítulo 6 Núcleo do sistema DOOR
- Page 101 and 102: 6.1. COOBJECTOS 83 o mesmo estado i
- Page 103 and 104: 6.2. SERVIDORES 85 global a associa
- Page 105 and 106: 6.2. SERVIDORES 87 segundo servidor
- Page 107 and 108: 6.2. SERVIDORES 89 6.2.2 Sincroniza
- Page 109 and 110: 6.2. SERVIDORES 91 6.2.3 Serviço d
- Page 111 and 112: 6.2. SERVIDORES 93 ao cliente compl
- Page 113 and 114: 6.2. SERVIDORES 95 • Emulação d
- Page 115 and 116: 6.3. CLIENTES 97 do coobjecto consi
- Page 117 and 118: 6.3. CLIENTES 99 seguinte informaç
- Page 119 and 120: 6.3. CLIENTES 101 A propagação as
- Page 121 and 122: Capítulo 7 Apresentação do siste
- Page 123 and 124: 7.1. MODELO GERAL 105 encomenda de
- Page 125 and 126: 7.2. ARQUITECTURA 107 BD réplica C
- Page 127 and 128: 7.2. ARQUITECTURA 109 O subsistema
- Page 129 and 130: 7.3. TRANSACÇÕES MÓVEIS 111 7.3
- Page 131 and 132: 7.3. TRANSACÇÕES MÓVEIS 113 abor
- Page 133 and 134: Capítulo 8 Reservas Neste capítul
- Page 135 and 136: 8.1. TIPOS DE RESERVAS 117 8.1.4 Re
- Page 137 and 138: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 139 and 140: 8.2. CONCESSÃO E GARANTIA DE RESPE
- Page 141 and 142: 8.3. PROCESSAMENTO DAS TRANSACÇÕE
- Page 143 and 144: 8.4. PROCESSAMENTO DAS TRANSACÇÕE
- Page 145: 8.5. EXEMPLOS 127 id tipo tabela co
- Page 149 and 150: Capítulo 9 Avaliação do modelo b
- Page 151 and 152: 9.1. APLICAÇÕES 133 1 ------ REMO
- Page 153 and 154: 9.2. RESERVAS 135 dentemente em dif
- Page 155 and 156: 9.2. RESERVAS 137 seguinte forma. P
- Page 157 and 158: 9.2. RESERVAS 139 Commit (% total)
- Page 159 and 160: 9.2. RESERVAS 141 Commit (% total)
- Page 161 and 162: 9.2. RESERVAS 143 Commit (% total)
- Page 163 and 164: 9.2. RESERVAS 145 Commit (% total)
- Page 165 and 166: 9.2. RESERVAS 147 Por exemplo, no c
- Page 167 and 168: Capítulo 10 Sistema de reconcilia
- Page 169 and 170: 10.2. RELAÇÕES ESTÁTICAS 151 10.
- Page 171 and 172: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 173 and 174: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 175 and 176: 10.3. ALGORITMO DE RECONCILIAÇÃO
- Page 177 and 178: 10.4. OPTIMIZAÇÃO DA RECONCILIAÇ
- Page 179 and 180: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 181 and 182: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 183 and 184: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 185 and 186: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 187 and 188: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 189 and 190: 10.5. EXTRACÇÃO AUTOMÁTICA DE RE
- Page 191 and 192: Capítulo 11 Trabalho relacionado A
- Page 193 and 194: 11.1. REPLICAÇÃO 175 11.1.2 Arqui
- Page 195 and 196: 11.1. REPLICAÇÃO 177 a unidade de
128 CAPÍTULO 8. RESERVAS<br />
tipo tabela coluna condição valor informação<br />
escrow trains available train=’London-Paris 10:00’ 2 ≥ 0<br />
value-use trains price AND 95.00 -<br />
value-change tickets * day=’18-FEB-2002’ (4A, f alse,...) -<br />
value-change tickets * (4B, f alse,...) -<br />
Tabela 8.3: Reservas obtidas pelo garantir reservas <strong>de</strong> bilhetes <strong>de</strong> comboio (i<strong>de</strong>ntificador, ligação e data<br />
<strong>de</strong> expiração omitidos).<br />
tipo tabela coluna condição valor<br />
value-lock trainsids * true todos os registos<br />
value-use trains price train=23 AND day=’18-FEB-2002’ 95.00<br />
value-change tickets * train=23 AND day=’18-FEB-2002’ (4A, f alse,...)<br />
value-change tickets * train=23 AND day=’18-FEB-2002’ (4B, f alse,...)<br />
Tabela 8.4: Reservas obtidas pelo garantir reservas <strong>de</strong> bilhetes <strong>de</strong> comboio: segunda alternativa (i<strong>de</strong>nti-<br />
ficador, ligação, informação e data <strong>de</strong> expiração omitidos).<br />
nome do passageiro associada a esse lugar (linhas 10-11).<br />
Vamos assumir que o cliente obteve reservas sobre dois lugares do comboio: as reservas respectivas<br />
são apresentadas na tabela 8.3. O processamento da transacção <strong>móvel</strong> prossegue <strong>de</strong> forma similar ao<br />
ex<strong>em</strong>plo anterior até ser necessário obter o i<strong>de</strong>ntificador do lugar a usar. A instrução select (linhas 8-9),<br />
que obtém o i<strong>de</strong>ntificador do lugar, <strong>de</strong>volve um dos lugares reservados porque as instruções <strong>de</strong> leitura<br />
<strong>de</strong>volv<strong>em</strong> preferencialmente valores reservados. Neste caso, po<strong>de</strong>r-se-ia obter, por ex<strong>em</strong>plo, o lugar<br />
“4A”. A instrução update (linhas 10-11) actualiza a informação relativa ao lugar “4A” com o nome do<br />
passageiro e o preço do bilhete. Estas instruções são garantidas pela reserva value-change que o cliente<br />
<strong>de</strong>tém sobre o registo que mantém a informação do lugar “4A”. Quando a transacção <strong>móvel</strong> é executada<br />
no servidor, o sist<strong>em</strong>a garante que a instrução select <strong>de</strong>volve o mesmo registo, i.e., o registo relativo ao<br />
lugar “4A”. Assim, o resultado da transacção no cliente é o nível full <strong>de</strong> reservation commit (todas as<br />
instruções são garantidas).<br />
Se as reservas value-change não estivess<strong>em</strong> disponíveis, seria impossível garantir as instruções <strong>de</strong><br />
leitura e escrita relacionadas com o lugar (linhas 8–11). O resultado da instrução select seria obtido a<br />
partir da versão provisória dos <strong>dados</strong>. Assim, o resultado da execução local da transacção seria o nível<br />
pre-condition <strong>de</strong> reservation commit. Para esta transacção, este resultado significa que é possível garantir<br />
a disponibilida<strong>de</strong> e preço do lugar, mas é impossível garantir o lugar que será atribuído ao passageiro.<br />
Na figura 8.3 apresenta-se uma versão alternativa para reservar um lugar num comboio. Neste ex<strong>em</strong>-<br />
plo, a base <strong>de</strong> <strong>dados</strong> mantém uma tabela que associa o nome do comboio com o seu i<strong>de</strong>ntificador (um<br />
inteiro). Adicionalmente, não existe informação sobre o número <strong>de</strong> lugares disponíveis: este valor é<br />
obtido contando o número <strong>de</strong> lugares não ocupados.<br />
Na tabela 8.4 apresentam-se as reservas obtidas para garantir dois lugares. Relativamente à versão