TRANSAÇÕES E CONTROLE DE CONCORRÊNCIA Em resumo: Transações: clientes podem necessitar que um servidor execute uma sequência de requisições de forma a

Transcrição

1 Transações Transações Uma transação é um conjunto de operações que deve ser executado de forma atômica Atômica : se um erro ocorre no meio da transação, devemos voltar ao estado consistente anterior. Atômica 2: ou todas as operações são realizadas ou nenhuma é realizada. Exemplo de transação bancária Transferir R$00,00 da conta A para a conta B A.retirar (00,00) B.depositar (00,00) Transação composta por duas operações deve ser executada de forma atômica senão situação das contas pode ser inconsistente!!! Sist. Distrib. II - Prof. Cesar A. Tacla Sist. Distrib. II - Prof. Cesar A. Tacla 2 Transações Transações: commit e rollback Uma transação pode ser vista como uma unidade Durante a execução, várias operações são realizadas e resultados intermediários são produzidos Se todas as operações são realizadas com sucesso, a transação pode ser commited (efetivamente realizada, durável) Se uma das operações falha, um processo chamado de rollback retorna ao último estado consistente (para o último commitment) Estado inicial: A.saldo() = R$ 50,00 B.saldo() = R$ 0,00 A.retirar (00,00)[OK] Estado intermediário: A.saldo() = R$ 50,00 B.saldo() = R$ 0,00 B.depositar (00,00) Estado final: A.saldo() = R$ 50,00 B.saldo() = R$ 00,00 Fim transação/commit A.retirar (00,00)[ERRO]/rollback B.depositar(00,00)[ERRO]/rollback Sist. Distrib. II - Prof. Cesar A. Tacla 3 Sist. Distrib. II - Prof. Cesar A. Tacla 4 Transações: commit e rollback Transações: isolamento ESTADO INICIAL OPERAÇÕES DA TRANSAÇÃO EM EXECUÇÃO ERRO/ROLLBACK Transação x := A.getSaldo() // R$00,00 A.setSaldo(x + 50) // R$50,00 abort Transação 2 y := A.getSaldo() // R$50,00 A.setSaldo(y+30) // R$80,00 Fim ok transação/commit Uma transação termina: com sucesso: todos objetos/registros são salvos permanentemente (durabilidade) com erro: o cliente ou o servidor podem abortar a transação Uma transação não pode enxergar os resultados intermediários produzidos por uma outra!!! (dirty read) Sist. Distrib. II - Prof. Cesar A. Tacla 5 Sist. Distrib. II - Prof. Cesar A. Tacla 6

2 TRANSAÇÕES E CONTROLE DE CONCORRÊNCIA Em resumo: Transações: clientes podem necessitar que um servidor execute uma sequência de requisições de forma atômica Existem mecanismos (CORBA, jbeans, BDs) que permitem ao programador enxergar cada transação como um programa sequencial mesmo que executada em concorrência com outras ou que ocorram falhas durante a sua execução Transação é uma seqüência de operações que devem ser tratadas como uma unidade sendo executadas serialmente e sem interrupção ou que podem ser executadas concorrentemente, mas com o mesmo efeito de uma execução serial. Transações: propriedades ACID Atomicidade: uma transação deve ser executada totalmente ou não ter nenhum efeito Consistência: uma transação leva o sistema de um estado consistente a outro estado consistente Isolamento: Cada transação deve ser executada sem interferência de outras transações, mesmo quando elas forem executadas concorrentemente, por isso resultados intermediários por uma transação são invisíveis às outras. Durabilidade: quando uma transação é executada com sucesso, seus efeitos são persistentes Sist. Distrib. II - Prof. Cesar A. Tacla 7 Sist. Distrib. II - Prof. Cesar A. Tacla 8 Transações: propriedades ACID Exemplo consistência e atomicidade Transferência de R$50,00 da conta A para a conta B.. read(a) 2. A := A write(a) 4. read(b) 5. B := B write(b) Consistência: a soma de A e B deve permanecer inalterada ao final da transação. Atomicidade: se a transação (ou qualquer componente do sistema) falhar após o passo 3 e antes do passo 6, o sistema deve garantir que a alteração não se reflita na base de dados. Atualização perdida Quando uma transação sobrescreve o valor escrito por outra. T sobrescreve o saldo escrito por T2 Transação t saldo := b.saldo( ); // R$0 b.setsaldo(saldo *,); // R$2 tempo Transação t2 saldo := b.saldo( ); // R$0 b.setsaldo(saldo*,); // R$0 Saldo final da conta b ficou R$ 2,00 mas deveria ser: R$ 242,00 Uma das atualizações foi perdida porque as transações leram o saldo antigo de b!!! Sist. Distrib. II - Prof. Cesar A. Tacla 9 Sist. Distrib. II - Prof. Cesar A. Tacla 0 Leitura inconsistente Quando uma transação lê valores intermediários de outra transação atributos que estão sendo modificados em outra transação Transação t a.retirar(00) // R$00 b.depositar(00) // R$300 tempo Transação t2 total = a.saldo( ); // R$00 total = total + b.saldo( ); // R$300 total = total + c.saldo( ); Saldo inicial de a e b = R$0,00 t modifica os saldos de a e b enquanto t2 faz o somatório dos saldos de todas as contas de uma agência Como T2 fez leitura inconsistente, a variável total (linha 2, t2) contém R$300 ao invés de R$400!!! Como resolver estes problemas? Com exclusão mútua Utilizar métodos sincronizados (ex. Java) public synchronized void depositar(int valor) throws RemoteException Utilizar um algoritmo de exclusão mútua Utilizar primitivas wait/notifiy um processo servidor notifica um cliente que está aguardando o acesso a um objeto Um servidor de objetos recuperáveis Sist. Distrib. II - Prof. Cesar A. Tacla Sist. Distrib. II - Prof. Cesar A. Tacla 2 2

3 Um servidor de objetos recuperáveis que garanta o acesso isolado aos objetos compartilhados Permite delimitar o início e o fim da transação EXEMPLO JTA = Java transaction API opentransaction() -> trans; Inicia uma nova transação e retorna um identificador único trans. closetransaction(trans) -> (commit, abort); Finaliza a transação: retorna commit se terminou OK ou abort caso contrário aborttransaction(trans); Aborta a transação. roolbacktransaction(trans) Sist. Distrib. II - Prof. Cesar A. Tacla 3 Sist. Distrib. II - Prof. Cesar A. Tacla 4 Do ponto de vista do programador, as propriedades ACID de um transação são normalmente garantidas por um servidor de objetos recuperáveis e sua API (JTA, SGBDs) Internamente, o que acontece? equivalência serial: consiste em intercalar as operações das transações de forma que o resultado produzido seja o mesmo que se as transações tivessem sido executadas sequencialmente. Mesmo resultado significa: As operações de leitura retornam os mesmos valores que numa execução sequencial As variáveis dos objetos tem os mesmos valores no final da execução que numa execução sequencial Como realizar uma interacalação Numa execução sequencial, uma transação executa as operações que referenciam as variáveis em conflito antes da outra transação Conflito: ocorre quando uma das transações modifica uma variável e a outra transação lê ou modifica a mesma variável Logo, numa intercalação serial equivalente (T e U são transações): T executa as operações conflitantes antes de U ou U executa as operações conflitantes antes de T Sist. Distrib. II - Prof. Cesar A. Tacla 5 Sist. Distrib. II - Prof. Cesar A. Tacla 6 Transações: Intercalação é equivalente a execução serial Exemplo de intercalação: T: ; ; write(i, 0) U: ; write(j, 30); z=read(i) Intercalação: transação T executa operações conflitantes sobre as variáveis i e j antes da transação U write(i,0) Inicialmente i = j = 2 Execução T antes de U Serial i 0 j 30 write(i,0) x y z 0 write(i,0) Intercalação Sist. Distrib. II - Prof. Cesar A. Tacla 7 Sist. Distrib. II - Prof. Cesar A. Tacla 8 3

4 Transações: Intercalação é equivalente a execução serial write(i,0) Execução U antes de T i j write(i, 0) x y=read(j) write(j, 30) y z Exercício xt=read(j) ; yt=read(i); write(j, 44); write(i, 33) xu=read(k); write(i, 55); yu=read(j); write(k, 66) Encontre 2 intercalações equivalentes a execução serial de T e U Serial 0 2 Intercalação 0 2 Sist. Distrib. II - Prof. Cesar A. Tacla 9 Sist. Distrib. II - Prof. Cesar A. Tacla Transações: recuperação em caso de abort Exemplo de não-equivalência: T acessa i antes de U, porém T acessa j depois de U Transaction T: Transaction U: Quando uma transação aborta, o servidor deve tomar as precauções para que as outras transações concorrentes não observem os efeitos intermediários da transação abortada write(i, 0) write(j, 30) Figure 2.0 Dois problemas podem ocorrer Leituras com ru z = read (i) Sist. Distrib. II - Prof. Cesar A. Tacla 2 Sist. Distrib. II - Prof. Cesar A. Tacla 22 Transações: leituras com ru Transações: leituras com ru : s = a.getsaldo() a.setbalance(balance + 0) s = a.getsaldo() $00 a.setsaldo(s + 0) $0 Figure 2. abort transaction : s = a.getsaldo() a.setbalance(balance + ) s = a.getsaldo() $0 a.setsaldo(s + ) $30 commit transaction A execução intercalada é equivalente à serial T aborta quando U já havia realizado o commit U não pode voltar atrás. Problema de consistência pois o saldo correto seria de $ e não $30 Sist. Distrib. II - Prof. Cesar A. Tacla 23 Recuperação No caso anterior, a situação é irrecuperável. U pegou um resultado intermediário de T e realizou o commit. Após o commit não pode voltar atrás. Para termos uma situação recuperável, U deve fazer o commitment somente após T fazê-lo. Se T abortar, toda transição que observou um resultado intermediário de T deve abortar também Problema: aborts em cascata Sist. Distrib. II - Prof. Cesar A. Tacla 24 4

5 Transações: leituras com ru Recuperação do abort em cascata No exemplo, U deve abortar também Além disso, todas as transações que «viram» os efeitos de U devem também abortar e assim por diante Para evitar aborts em cascata: Uma transação somente pode ler um objeto que foi modificado por transações que já realizaram o commit ou abortaram. Logo, toda operação de leitura deve esperar que todas as transações que tenham feito um write no objeto façam o commit ou abortem. No exemplo, U deve esperar até que T aborte para fazer a.getsaldo() Transações: escritas prematuras : : Im = $00 a.setsaldo(05) $05 abort Im = $05 a.setsaldo(0) $0 commit Alguns SGBDs guardam imagens antes das atualizações Ex. antes do setsaldo em T temos imagem = $00 Antes do setbalance em U temos imagem = $05 Se U aborta, obteremos o saldo correto = $05 Mas, se T aborta (após commitment de U) voltaremos a ter saldo = $00!!! ERRO!!! Sist. Distrib. II - Prof. Cesar A. Tacla 25 Sist. Distrib. II - Prof. Cesar A. Tacla 26 Transações: escritas prematuras Transações: recuperação em caso de abort Para assegurar resultados corretos quando este esquema de imagem é utilizado deve-se: Fazer as operações de escrita somente depois que as transações anteriores (que acessam os mesmos objetos) tenham feito commitment ou tenham abortado Execuções ESTRITAS de transações As operações de leitura e de escrita aguardam até que as transações anteriores tenham committed ou abortado Isto reforça a propriedade de isolamento Em resumo, para evitar Leituras com ru Sist. Distrib. II - Prof. Cesar A. Tacla 27 Sist. Distrib. II - Prof. Cesar A. Tacla 28 Transações aninhadas Transações aninhadas: características T : top-level transaction T = opensubtransaction T 2 = opensubtransaction T : T 2 : opensubtransaction opensubtransaction T : T 2 : Figure 2.3 T 2 : Transações são compostas de outras transações Uma transação pode iniciar várias subtransações Subtransações podem ter subtransações opensubtransaction opensubtransaction T 2 : prov.commit commit abort Para uma transação pai, as subtransações são atômicas Transações de mesmo n Sist. Distrib. II - Prof. Cesar A. Tacla 29 Sist. Distrib. II - Prof. Cesar A. Tacla 30 5

6 Transações aninhadas: vantagens sobre as planas Transações aninhadas: commitment Transações aninhadas permitem maior concorrência Subtransações de mesmo n Uma transação pode abortar ou fazer commit somente se suas subtransações já completaram Quando uma subtransação completa, ela pode fazer commit provisório ou abortar. A decisão de abortar é final Quando uma transação pai aborta, todos as subtransações abortam (mesmo que tenham feito um commit provisório) Se uma subtransação aborta então o pai pode decidir abortar ou não. Se a transação top-level faz commit, então todas as subtransações que já fizeram o commit provisório podem fazer o commit definitivo, desde que seus ancestrais não tenham abortado. Se T commits então T, T e T2 podem fazer o commit. Supondo que T2 tenha abortado, T2 e T22 não poderiam fazer o commit. Sist. Distrib. II - Prof. Cesar A. Tacla 3 Sist. Distrib. II - Prof. Cesar A. Tacla 32 Transações aninhadas: estados de uma transação Transações: implementação Uma transação não pode escrever diretamente no objeto partilhado em uso Se isso acontecer, a transação não será atômica e nem isolada das outras transações concorrentes Implementações: Workspace privado Log Sist. Distrib. II - Prof. Cesar A. Tacla 33 Sist. Distrib. II - Prof. Cesar A. Tacla 34 Transações: implementação Transações: implementação Workspace privativo As transações utilizam um espaço separado e temporário; Todas as alterações são gravadas nesse espaço temporário; O problema dessa técnica é que é muito cara (e demorada); Uma otimização pode ser feita mantendo somente os blocos do arquivo alterados no workspace privativo (p. 492); Essa técnica é chamada de shadow blocks; Lista de intenções (Writeahead log ou Intentions log) Uma outra forma de implementar transações é através de um log de modificações; Nesse caso, os arquivos são modificados diretamente no SO, mas antes um log de modificações é gerado; Nesse log, estão contidos o estado original dos objetos modificados bem como o novo valor modificado; Se a transação termina, uma entrada commit é gravada no log; Se a transação é cancelada, as modificações são revertidas com base no log - essa operação é chamada de rollback; Sist. Distrib. II - Prof. Cesar A. Tacla 35 Sist. Distrib. II - Prof. Cesar A. Tacla 36 6