Anda di halaman 1dari 14

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

11

Desenvolvimento de um mecanismo de transaes para sistemas distribudos


Christiano Borchardt (FURB)
christiano@wk.com.br

Marcel Hugo (FURB)


marcel@furb.br Resumo. Este trabalho consiste na pesquisa sobre o funcionamento de sistemas de processamento de transaes em ambientes distribudos e as tcnicas para garantir o funcionamento das propriedades ACID de transaes. Como resultado obteve-se a implementao de um mecanismo de gerenciamento de transaes distribudas utilizando o protocolo de consolidao de duas fases e o algoritmo de registro de log de refazer, na forma de uma biblioteca de classes para ser utilizada por desenvolvedores da ferramenta Visual C++, realizando a comunicao de objetos distribudos via DCOM da Microsoft. Palavras-chave: Transaes, sistemas distribudos, 2PC.

1 Introduo
Para Raynal (2001), sistemas distribudos so difceis de modelar e de implementar, por causa da imprevisibilidade e demora de transferncia de mensagens, velocidade de execuo de processos e tratamento de falhas. Tais variveis tornam o sistema vulnervel a anormalidades, principalmente quando este estiver executando uma transao envolvendo diversas operaes. Uma transao possui quatro propriedades que devem ser atendidas (ACID): atomicidade - a transao executa completamente ou no executa nada; consistncia - deve preservar a consistncia interna da base de dados; isolamento protegida dos efeitos da execuo de outras transaes concorrentes; e durabilidade - o resultado de uma transao no deve ser perdido por motivo de falha (Bernstein, 1997). No gerenciamento de transaes em ambientes distribudos, atualmente necessria a presena de um banco de dados com estas caractersticas avanadas. No entanto, o custo de aquisio e gerenciamento de um banco de dados deste tipo no acessvel para usurios de aplicao de pequeno e mdio porte. Este artigo relata a implementao de uma biblioteca de gerenciamento de transaes em ambientes distribudos para uso da ferramenta Visual C++ 6.0. A comunicao entre os componentes distribudos feita utilizando-se a tecnologia COM/DCOM da Microsoft, e a gravao dos dados feita atravs de sistema de arquivos, sem o uso de banco de dados.

12

XI SEMINCO - Seminrio de computao - 2002

2 Protocolo de consolidao de duas fases


Segundo Bernstein (1997), quando uma transao atualiza dados em dois ou mais sistemas em um ambiente distribudo, h que se assegurar a propriedade de atomicidade, isto , ou ambos os sistemas consolidam suas atualizaes, ou nenhum. A soluo um protocolo especial chamado two-phase commit (2PC) consolidao de duas fases, que executado por um mdulo especial chamado gerenciador de transao. O ponto principal do problema que uma transao pode consolidar suas atualizaes em um sistema, mas o segundo sistema pode falhar antes que a transao as consolide tambm. Neste caso, quando o sistema que falhou se recuperar, ele deve estar apto a consolidar a transao. Segundo Garcia-Molina (2001), seguem-se vrios pontos de destaque sobre o protocolo de consolidao de duas fases: - Em uma consolidao de duas fases, supe-se que cada local anota as aes desse local, mas no h nenhum log global; - Tambm supe-se que um local, chamado de coordenador, desempenha um papel especial no ato de decidir se a transao distribuda pode ou no ser consolidada; - O protocolo de consolidao de duas fases envolve o envio de certas mensagens entre o coordenador e os outros locais. medida que cada mensagem enviada, ela anotada no local de envio, para ajudar na recuperao, caso seja necessrio. Com esses pontos em mente, pode-se descrever as duas fases em termos das mensagens enviadas entre os locais. Fase I Segundo Garcia-Molina (2001), na primeira etapa da consolidao de duas fases, o coordenador para uma transao distribuda T decide quando deve tentar consolidar T. Supe-se que a tentativa de consolidao ocorre aps o componente de T no local do coordenador estar pronto para consolidar mas, em princpio, as etapas devem ser executadas ainda que o componente do coordenador queira abortar (mas com simplificaes bvias, como ser visto). O coordenedor consulta todos os locais com componentes de transao T, a fim de determinar sua opinio em relao deciso de consolidar/abortar: 1. O coordenador insere um registro de log <Prepare T> no log de seu local (os principais algoritmos de registro de log podem ser vistos em (GarciaMolina,2001)); 2. O coordenador envia para cada local do componente (em princpio, incluindo a si mesmo) a mensagem prepare T; 3. Cada local que recebe a mensagem prepare T decide se deve consolidar ou abortar seu componente de T. O local pode se atrasar, se o componente ainda

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

13

no tiver completado sua atividade, mas eventualmente deve enviar sua resposta; 4. Se um local quiser consolidar seu componente, deve entrar em um estado chamado pr-consolidado. Uma vez no estado de pr-consolidado, o local no poder abortar seu componente de T sem uma orientao para faz-lo do coordenador. As etapas a seguir so executadas de forma que o componente se torne pr-consolidado: - Executar toda as etapas necessrias para assegurar que o componente local de T no ter de abortar, ainda que exista uma falha do sistema seguida pela recuperao no local. Desse modo, no apenas todas as aes associadas com a T local sero executadas, mas as aes apropriadas relativas ao log devem ser executadas de forma que T seja refeita, em vez de ser desfeita em uma recuperao. As aes dependem do mtodo de registro de log, mas seguramente os registros de log associados com as aes de T local tero de ser esvaziados para o disco. - Inserir o registro <Ready T> no log e esvaziar o log para o disco. - Enviar ao coordenador a mensagem ready T. Porm, o local no consolida seu componente de T nesse momento; ele deve esperar pela fase 2. 5. Se, em vez disso, o local quiser abortar seu componente de T, ento ele anotar o registro <Dont Commit T> e enviar a mensagem dont commit T ao coordenador. seguro abortar o componente nesse momento, pois T sem dvida abortar se at mesmo um componente quiser abortar. Fase II Segundo Garcia-Molina (2001), a segunda fase comea quando as respostas ready ou dont commit so recebidas de cada local pelo coordenador. Porm, possvel que algum local deixe de responder; ele pode estar fora de servio ou pode ter sido desconectado pela rede. Nesse caso, depois de um espao de tempo limite satisfatrio, o coordenador tratar o local como se ele tivesse enviado um dont commit. 1. Se o coordenador tiver recebido ready T de todos os componentes de T, ento ele decidir consolidar T. O coordenador: - Anota <Commit T> em seu log local, e - Envia a mensagem commit T a todos os locais envolvidos em T. 2. Se tiver recebido dont commit T de um ou mais locais, o coordenador: - Anotar <Abort T> em seu log local e, - Enviar mensagens abort T a todos os locais envolvidos em T.

14

XI SEMINCO - Seminrio de computao - 2002

3. Se um local receber uma mensagem commit T, ele consolidar o componente de T nesse local, anotando <Commit T> ao faz-lo; 4. Se um local receber a mensagem abort T, ele abortar T e gravar o registro de log <Abort T>. A figura 1 mostra as mensagens das fases I e II.

Gerenciador de Transaes 1.prepare 1. prepare 2 . Im prepared (ready) 3. commit 2. Im prepared (ready)

Gerenciador de Transaes 3. commit 4. OK 4. OK

Gerenciador de recursos em N.Y

Gerenciador de recursos em Londres

Gerenciador de recursos em N.Y

Gerenciador de recursos em Londres

Fase I

Fase II

Figura 1: Mensagens das fases I e II

3 Desenvolvimento da biblioteca
3.1 Requisitos principais do problema a ser trabalhado Os requisitos identificados para este trabalho foram: a) a biblioteca no deve permitir que mais de uma transao execute ao mesmo tempo (uma forma de garantir o isolamento, pela execuo serial das transaes); b) a biblioteca, se utilizada corretamente, deve garantir que a consistncia da base de dados seja mantida mesmo com a ocorrncia de falhas (consistncia); c) deve ser garantido que ou uma transao executa todas as suas operaes com sucesso ou nenhuma operao ter efeito (atomicidade);

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

15

d) deve ser garantido que depois que uma transao terminar suas tarefas com sucesso, seus resultados nunca sero perdidos (durabilidade). 3.2 Diagrama de casos de uso Na modelagem desta biblioteca foram observados sete casos de uso (fig. 2), que so descritos a seguir: a) inicializar transaes: o usurio (neste trabalho, este o desenvolvedor da aplicao) inicializa a sua aplicao para o uso da biblioteca de transaes; b) iniciar transao: o usurio inicia uma transao onde ele realiza todas as operaes que envolvem essa transao; c) abrir arquivo: o usurio abre cada arquivo onde sero realizadas as operaes da transao atual; d) ler registro: o usurio executa uma operao de leitura de um registro de um determinado arquivo, o qual foi aberto anteriormente e faz parte da transao atual; e) gravar registro: o usurio executa uma operao de gravao em um registro de um determinado arquivo, o qual foi aberto anteriormente e faz parte da transao atual; f) consolidar transao: o usurio consolida todas as operaes realizadas desde que ele iniciou essa transao; g) abortar transao: o usurio aborta, ou seja, cancela todas as operaes realizadas desde que ele iniciou essa transao.

Inicializar Transaes

Usurio

Iniciar Transacao

Abrir Arquivo

Abortar Transao Consolidar Transao Gravar Registro

Ler Registro

Figura 2: Diagrama de casos de uso

16

XI SEMINCO - Seminrio de computao - 2002

3.3

Diagrama de classes

As classes do diagrama da figura 3 so descritas a seguir: a) CFile: uma classe da biblioteca MFC (Microsoft Foundation Class) e utilizada como classe base porque possui as operaes primitivas de acesso, leitura e gravao de arquivos; b) CArqLog: esta classe derivada da classe CFile e possui as operaes bsicas de leitura e gravao de log, bem como do prprio estado do log (deve-se destacar, para o melhor entendimento do mecanismo, que o mtodo de log utilizado o de Refazer) ; c) CArqTransac: esta classe derivada de CFile e usada diretamente pelo usurio para realizar todas as operaes da transao. Esta classe tambm encapsula toda a comunicao com o coordenador e faz o gerenciamento do buffer de operaes e do log atravs da classe CArqLog; d) CCallBackCoordenador: esta classe utilizada pela classe CArqTransac e serve para fazer as operaes de CallBack entre ela e o coordenador. Portanto, ela responsvel pelo recebimento e tratamento de todas as notificaes vindas do coordenador atravs do mecanismo de Connection Points; e) CCoordenador: esta classe implementa a interface de comunicao do componente que coordena as transaes, e responsvel por todo o gerenciamento das transaes, como: Escalonamento das transaes, controle de time out, protocolo de consolidao de duas fases (2PC), e gerenciamento do log global; f) CServiceModule: uma classe gerada pela ferramenta Visual C++ 6.0 atravs do ATL COM AppWizard, e responsvel pelo servio de registro e comunicao do componente. Ela utilizada pela classe CCoordenador na gerncia de transaes, pelo fato de ser criada em uma nica instncia, o que facilita no controle das diversas transaes. Esta classe tambm possui mecanismos de bloqueio que permitem apenas uma transao acessar os dados de cada vez; g) CEscalonador: utilizada pela classe CServiceModule, implementa os mtodos necessrios para gerenciar uma fila de requisies de incio de transao. Ela garante que apenas uma transao execute de cada vez, e faz com que as transaes adquiram seus recursos na mesma ordem que foram feitas as requisies; h) CTransao: esta classe utilizada diretamente pelo usurio, e responsvel pelas chamadas de incio de transao, cancelamento e consolidao das mesmas. Ela tambm encapsula a comunicao com o componente coordenador.

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

17

CFile CArqLog m_iTamRegistro m_lIDTransac int PegaTamanho( ) Reset( ) GravaEstadoLog( ) GravaRegistroLog( ) LeProximoRegistro( ) LePrimeiroRegistro( ) LeEstadoLog( ) Abre( ) Fecha( ) Possui 1 1

CArqTransac m_dwCookie m_iTamRegistro Abre( ) Fecha( ) Le( ) Grava( ) Prepare( ) Commit( ) Abort( ) EstaOcupado( ) GetQtdRegistros( ) ConsolidaLog( ) EsvaziaBuffer( ) LimpaBuffer( ) GerenciaMensagens( )

Associa-se

CCallBackCoordenador m_dwThreadID Invoke( ) SetCookieTransacao( ) SetThreadID( ) CServiceModule m_dwCookieTransac m_dwNumVotantes m_lIDTransacao AdicionaTransacao( ) RemoveTransacao( ) FazVotacao( ) FinalizaLogGlobal( ) InicializaLogGlobal( ) GetCookieAtual( ) GetNovoCookie( ) GetResultadoVotacao( ) GetResultadoTransacao( ) GravaLogGlobal( )

1..* Coordena 1 CCoordenador m_lIDTransac AbortaTransacao( ) Commit( ) GetCookieTransacao( ) GetNovoCookieTransacao( ) GetIDTransacao( ) GetResultadoTransacao( ) IniciaTransacao( ) Pronto( ) GetVotacaoParticipantes( ) KillTimer( ) EsperaPelaVez( ) ThreadTimeOut( )

Associa-se 1 1..*

1 Faz Parte 1 CEscalonador m_pPrimTransac m_pUltTransac AdicionaTransacao( ) RemoveTransacao( ) GetCookieAtual( )

1 Coordena 1..* CTransacao m_dwCookie Inicializa( ) IniciaTransacao( ) AbortaTransacao( ) ConsolidaTransacao( )

Figura 3: Diagrama de classes

18

XI SEMINCO - Seminrio de computao - 2002

3.4

Diagramas de sequncia O primeiro diagrama o iniciar transao identificado na figura 4. Este processo faz com que a partir da todas as operaes realizadas utilizando-se da classe CArqTransac pertenam a essa transao. Depois de chamado o mtodo IniciaTransacao do objeto da classe CTransacao, o mesmo notifica ao coordenador o pedido de incio da transao, passando o cookie gerado na inicializao. O coordenador por sua vez requisita ao objeto da classe CServiceModule para adicionar esse pedido de incio ao escalonador, que colocar o cookie em uma fila de espera.

: Usurio

: CTransacao

: CCoordenador

: CServiceModule

: CEscalona

IniciaTransacao ( ) IniciaTransacao ( ) AdicionaTransacao ( ) AdicionaTransacao ( )

EsperaPelaVez ( )

InicializaLogGlobal ( )

Figura 4: Diagrama de sequncia - Iniciar Transao

Depois disso o coordenador no permite que a transao continue executando, a menos que o seu cookie seja o primeiro da fila. Caso no seja o primeiro da fila, a transao continua esttica at que as transaes anteriores terminem suas tarefas e retirem seus cookies da fila.

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

19

Quando a transao ganha a vez para executar, o componente coordenador gera um outro identificador para a transao atravs do mtodo InicializaLogGlobal do objeto da classe CServiceModule, s que este nunca dever ser repetido por outras transaes, pois ele gravado em todos os arquivos de log utilizados pela transao atual para fins de consulta posterior. Logo aps, o coordenador solicita a inicializao do log global para CServiceModule que gera um arquivo com a denominao do identificador gerado. Esse arquivo conter qual foi a deciso global da transao, caso algum componente no consiga se comunicar com o coordenador . O prximo diagrama abortar transao identificado na figura 5. Este processo responsvel pelo cancelamento de uma transao pelo usurio.

: Usurio

: CTransacao : CCoordenador : CServiceModule

: CCallBack Coordenador

: CArqTransac : CArqLog

AbortaTransacao ( ) AbortaTransacao ( ) GravaLogGlobal ( ) Invoke ( ) Abort ( ) GravaEstadoLog ( )

FinalizaLogGlobal ( ) RemoveTransacao ( )

Figura 5: Diagrama de sequncia Aborta Transao

O usurio solicita classe CTransacao para que esta aborte a transao corrente notificando o coordenador. Quando o coordenador receber uma notificao de cancelamento, ele primeiramente grava o log global com o status de abortado, para que se acontecer algum problema de comunicao com os componentes participantes, eles possam futuramente verificar qual foi a deciso

20

XI SEMINCO - Seminrio de computao - 2002

global. Aps isso, o coordenador dispara uma notificao aos participantes informando que a transao foi abortada. A classe de callback no componente participante recebe esta notificao e dispara uma mensagem para o objeto da classe de arquivos, que a recebe atravs da thread receptora de mensagens. Aps a thread identificar que a mensagem foi a de abortar, ela chama o mtodo correspondente no objeto da classe, que faz a gravao do estado do log atual e limpa o buffer de operaes. Depois do coordenador fazer a notificao aos participantes ele finaliza o arquivo de log global desta transao, e em seguida remove o cookie da transao da fila, para que a prxima transao que est esperando possa continuar sua execuo. O ltimo diagrama consolidar transao, que ilustrado na figura 6. Sem dvida este o diagrama mais complexo e mais importante, pois trata do processo mais importante de um gerenciador de transaes, que o processo de consolidao distribuda de transaes. O processo se inicia aps o usurio terminar todos os procedimentos de sua transao e decidir consolidar efetivamente a transao. Quando o coordenador recebe a deciso de consolidar a transao, ele inicia o processo de consolidao de duas fases (2PC) distribudo. Na primeira fase do protocolo o coordenador anota em seu log global o status de PREPARE. Aps feito isso, ele envia a mensagem PREPARE para todos os componentes participantes. A partir desse momento, o coordenador fica na espera de resposta de todos os participantes, dentro de um tempo limite. Quando um participante recebe a mensagem PREPARE ele esvazia o buffer, ou seja, grava todas as operaes realizadas que esto no buffer de operaes em log, e se tudo ocorrer bem ele responde ao coordenador atravs do mtodo PRONTO. Caso algum dos participantes no responder ou responder que no pode consolidar, os critrios adotados so os mesmos do diagrama da figura 5 (abortar transao). Na segunda das duas fases do 2PL, caso tudo ocorra normalmente e todos respondam PRONTO, ento o coordenador anota em seu log global o status de COMMIT e notifica todos os participantes enviando a mensagem COMMIT. Quando um participante recebe a mensagem COMMIT, ele consolida o seu log varrendo todo o arquivo de log e fazendo suas alteraes no arquivo de dados. Depois disso gravado no log local o status COMMIT para que se tenha certeza de que a transao esteja efetivamente consolidada.

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

21

: Usurio

: CTransacao

: CCoordenador

: CServiceModule

: CCallBack Coordenador

: CArqTransac

ConsolidaTransacao ( ) Commit ( ) GravaLogGlobal ( ) Invoke ( ) Prepare ( ) EsvaziaBuffe

Pronto ( ) GravaLogGlobal ( ) Invoke ( ) Commit ( ) ConsolidaLog

FinalizaLogGlobal ( )

RemoveTransacao ( )

Figura 6: Diagrama de sequncia Consolidar Transao

Implementao da biblioteca A implementao da biblioteca foi realizada atravs do ambiente de programao Visual C++ 6.0, onde foram utilizados conceitos de orientao a objetos para desenvolver as classes de gerenciamento de arquivo de dados e de log, bem como do coordenador de transaes. Para desenvolver o componente coordenador das transaes, foi necessrio tambm utilizar o conceito de objetos distribudos da Microsoft (COM/DCOM) para estabelecer a comunicao entre ele e os participantes das transaes.

3.5

22

XI SEMINCO - Seminrio de computao - 2002

Para a gravao dos arquivos de dados e de log, foi utilizado uma classe base da biblioteca MFC (Microsoft Foundation Class) da Microsoft , chamada CFile, que permite efetuar operaes bsicas de manipulao de arquivos. 3.6 Como usar a biblioteca criada Para o desenvolvedor da aplicao poder utilizar sem problemas os recursos do mecanismo de transaes, ele dever efetuar os seguintes procedimentos: Na aplicao principal, dever ser includo o arquivo header transacao.h para que possa ser utilizada a classe CTransacao; Nos componentes servidores participantes da transao, devero ser includos os arquivos header LibTransac.h e a static library LibTransac.lib , para que possa ser utilizada a classe de manipulao de arquivo CArqTransac.

Quando estiver implementando a aplicao, dever primeiramente instanciar um objeto da classe CTransacao e em seguida inicializ-lo. Feito isso, deve instanciar todos os componentes servidores que faro parte da transao, como mostra a figura 9 Aplicao exemplo de controle de caixa e estoque. Estes componentes estaro conectados aos servidores remotos.
CTransacao m_transacao;

HRESULT hr = m_transacao.Inicializa(); if(FAILED(hr)) { MessageBox("sistema de transacoes no inicializou com sucesso."); } hr = m_pICaixa.CoCreateInstance(CLSID_Caixa); if(FAILED(hr)) { MessageBox("falha ao inicializar servidor de caixa"); hr = m_pIEstoque.CoCreateInstance(CLSID_Estoque); if(FAILED(hr)) { MessageBox("falha ao inicializar servidor de estoque");

Figura 9: Inicializao dos componentes

Depois de feitas as inicializaes, caso tudo ocorra sem erros, pode-se efetuar as operaes das transaes, como ilustra a figura 10, que mostra a implementao do mtodo OnVender na aplicao exemplo, utilizando dois componentes servidores como sendo participantes da transao atual. A inicializao dos componentes participantes deve ocorrer obrigatoriamente depois de iniciada a transao, pois na inicializao do componente participante

Desenvolvimento de um mecanismo de transaes para sistemas distribudos

23

que os arquivos sero abertos e estes arquivos j devem pertencer a alguma transao. Caso algum componente participante seja inicializado antes do inicio da transao, este componente estar apto a receber todas as mensagens de outras transaes que podero estar executando naquele momento. Uma estrutura para a implementao de um componente servidor para usar o mecanismo de transaes demonstrada na figura 10, que descreve as funes principais do servidor de estoque que foi utilizado na aplicao exemplo. Portanto a maneira em que o arquivo aberto tem influncia no comportamento da transao e provavelmente far com que a transao no funcione corretamente.
m_transacao.IniciaTransacao(); if(FAILED(hr)) return; hr = m_pICaixa->Inicializa(); if(FAILED(hr)) { m_transacao.AbortaTransacao(); return; hr = m_pIEstoque->Inicializa(); if(FAILED(hr)) { m_transacao.AbortaTransacao(); return;

hr = m_pIEstoque->RetiraQuantidade(m_iQtdVendida); if(FAILED(hr)) { m_transacao.AbortaTransacao(); return; } hr = m_pICaixa->CreditaValor(lValorCaixa); if(FAILED(hr)) { m_transacao.AbortaTransacao(); return;

hr = m_transacao.ConsolidaTransacao(); if(SUCCEEDED(hr)) MessageBox(Transao executada com sucesso); m_pIEstoque->Finaliza(); m_pICaixa->Finaliza();


Figura 10: Utilizando uma transao

Foram realizados vrios testes do aplicativo exemplo, interrompendo as operaes em vrias etapas diferentes da transao, e constatou-se que o mecanismo comportou-se conforme o esperado.

24

XI SEMINCO - Seminrio de computao - 2002

Para executar uma aplicao que se utiliza da biblioteca de transaes distribudas, necessrio configurar em todos os computadores que faro parte das transaes o local onde vai estar o componente coordenador, atravs do aplicativo DCOMCNFG da Microsoft. No computador onde ficar localizado o coordenador, registrar o componente EXE e a DLL para que o sistema de registros do sistema operacional desta mquina possa reconhec-los. Mais detalhes sobre a especificao e uso da biblioteca podem ser vistos em Borchardt (2002).

4 Concluses
Para gerenciar transaes em um ambiente distribudo, o sistema gera um considervel nmero de troca de mensagens, e nota-se que o uso excessivo ou imprprio de transaes pode fazer com que a performance do sistema seja seriamente afetada, pois existem muitos casos onde no realmente necessrio utilizar processamento de transaes. A utilizao de modelos de objetos para gerenciar transaes distribudas extremamente vivel, principalmente pelo baixo custo de desenvolvimento, considerando que o desenvolvedor no precisa se preocupar com a operacionalidade da comunicao dos processos atravs da rede. O modelo de objetos COM da Microsoft fornece uma arquitetura que atende a maior parte das necessidades no desenvolvimento de um mecanismo de transaes distribudas, porm, pelo fato de ser um padro proprietrio e binrio, faz com que a performance do mecanismo fique diretamente relacionada com a performance da arquitetura implementada pela Microsoft.

Referncias bibliogrficas
BERNSTEIN, Philip A.; NEWCOMER, Eric. Principles of transaction processing. Reading: Morgan Kaufmann Publishers, 1997. BORCHARDT, Christiano M.; Desenvolvimento de um mecanismo gerenciador de transaes para sistemas distribudos. Trabalho de Concluso de Curso (Bacharelado em Cincias da Computao). Universidade Regional de Blumenau. Blumenau, 2002. GARCIA-MOLINA, Hector; ULLMAN, J.D; WIDOM, Jennifer. Implementao de sistemas de banco de dados. Traduo Vandenberg Dantas de Souza. Rio de Janeiro: Campus, 2001. RAYNAL, Michel; SINGHAL, Mukesh. Mastering agreement problems in distributed systems. IEEE Software, New York, v. 18, n. 4, p. 40-47, jul/ago. 2001.

Anda mungkin juga menyukai