Notas de Aula - MAC 5759 - Sistemas de Objetos Distribuídos

Aula 17 - 16/5/2002

Transações Distribuídas

• Uma forma de controlar o acesso concorrente a um grupo de objetos distribuídos
• É um paradigma de programação que visa simplificar a construção de aplicações
• Exemplo mais comum de problema de concorrência (conta bancária):
• Ação 1 (saca 100):
• le saldo do BD;
• saldo = saldo - 100;
• escreve saldo no BD;
• Ação 2 (saca 200):
• le saldo do BD;
• saldo = saldo - 200;
• escreve saldo no BD;
• Gostaríamos que depois que as duas ações fossem executadas, que o saldo final fosse 300 a menos do que o original mas se as operações são executadas concorrentemente pode acontecer o seguinte:
• Obj1: le saldo do BD; // saldoObj1 = 1000
• Obj2: le saldo do BD; // saldoObj2 = 1000
• Obj1: saldo = saldo - 100; // saldoObj1 = 900
• Obj2: saldo = saldo - 200; // saldoObj2 = 800
• Obj1: escreve saldo no BD; // escreve saldo 900 no BD
• Obj2: escreve saldo no BD; // escreve saldo 800 no BD
• Resultado final: apesar de retirar 300, o saldo final no BD é 800
• Solução: colocar ações conflitantes dentro de transações e pedir auxílio ao sistema (p.ex. middleware) para evitar que transações diferentes acessem os mesmos dados de forma conflitante.
• Operações básicas em transações:
• begin_transaction
• end_transaction (ou commit_transaction)
• abort_transaction (ou roll_back_transaction)
• Propriedades ACID:
• Atomicidade
• transferência de dinheiro em uma conta corrente é composta por duas operações:
• saque (x, poupança); deposito (x, conta_corrente);
• Consistência
• consistência do sistema é mantida (e.g. quantidade total de dinheiro no banco é constante em transações intra-banco)
• Isolamento
• transações concorrentes não interferem umas com as outras
• exemplo: Tanenbaum 3-17, pag. 149 (o sistema tem que escalonar as operações de forma que o resultado final seja algo possível de acontecer se as transações fossem executadas uma depois das outras).
• Durabilidade
• depois do commit, mudanças são estáveis
• Protocolo Commit de Duas Fases (Two-Phase Commit Protocol )
• Gray (1978)
• usado quando
• a transação envolve múltiplas partes em nós diferentes de um sistema distribuído
• todos os nós precisam conhecer o resultado da transação
• fases:
• preparação para o commit
• commit

Serviço de Transações CORBA

• Define uma série de interfaces para ajudar os programadores a lidar com transações
• O fato de que as requisições dos clientes estão dentro de uma transação pode ser visível ou não para os clientes (i.e., pode ser transparente ou não).
• Modo não-transparente: cliente tem que criar transação e passá-la como parâmetro em cada requisição
  
• Modo transparente: requisições CORBA que fazem parte de uma transação carregam consigo um contexto transacional (transactional context). A transação corrente pode ser obtida de CORBA::Current.

• Elementos do serviço de transações:
• Transactional Client
• é um programa que pode emitir requisições para vários objetos transacionais dentro da mesma transação;
• o objeto que inicia a transação é chamado de transaction originator
  
• Transactional Object
• é um objeto cujo comportamento é afetado pelo fato de ele receber requisições dentro de transações;
• ele pode também receber requisições que não fazem parte de transações
• em geral, lidam com dados persistentes que são modificados pelas transações
• um nontransactional object é um objeto para o qual tanto faz ser chamado dentro de uma transação ou não
• se um objeto não implementa comportamento transacional, não há como voltar ao estado anterior em caso de erros (aborto da transação)
• Não há nada na IDL que diz se uma operação é transacional ou não; funciona como uma propriedade não-funcional, uma propriedade de qualidade de serviço
• São usados para implementar dois tipos de servidores:
• Transactional Server
• Recoverable Server
• Recoverable Objects
• É um objeto cujo estado é afetado por um commit ou roll-back
• Objetos recuperáveis precisam colaborar com alguns protocolos do serviço de transações para que o commit e o roll-back funcione direito e que todos os participantes da transação tenham a mesma visão do resultado final
• Para participar desses protocolos, o objeto define um Resource e o registra com o serviço de transações
  
  enum Vote {
      VoteCommit,
      VoteRollback,
      VoteReadOnly
  };
  interface Resource {
      Vote prepare()
              raises(
              HeuristicMixed,
              HeuristicHazard
          );
      void rollback()
          raises(
              HeuristicCommit,
              HeuristicMixed,
              HeuristicHazard
          );
      void commit()
          raises(
              NotPrepared,
              HeuristicRollback,
              HeuristicMixed,
              HeuristicHazard
          );
      void commit_one_phase()
          raises(
              HeuristicHazard
          );
      void forget();
  };
  
  
• todo recoverable object é transacional mas o oposto não é necessário (um objeto transacional não recuperável pode não armazenar estado ou delegar essa armazenagem em outro objeto (recuperável)).
• As exceções Heuristic* são usadas para indicar que não foi possível obter um consenso no resultado da transação e que uma heurística foi utilizada para determinar qual o resultado adotado. Uma exceção destas indica que algo de errado aconteceu.
  
• Transactional Server
• É uma coleção de um ou mais objetos transacionais que não possuem estado recuperável próprios (eles usam outros objetos recuperáveis para isso)
• Ele não participa do fechamento da transação
• Mas pode abortar uma transação se algo dá errado
  
• Recoverable Server
• É uma coleção de um ou mais objetos transacionais sendo que pelo menos um deles é recuperável.
• Ele registra um ou mais Resources com o serviço.
• O serviço de transações dirige o protocolo de commit enviando requisições para os resources .

• Atividades do Serviço de Transações
• Controlar o escopo e a duração de uma transação
• Permitir que vários objetos se envolvam com uma única transação atômica
• Permitir que objetos associem mudanças em seu estado interno a transações
• Coordenar o fechamento de uma transação
• Transações podem ser
• planas (flat) - obrigatório
• aninhadas - de implementação não-obrigatória
• Como parte do ambiente de execução do ORB, cada thread pode carregar um contexto de transação
• Esse contexto pode ser nulo (thread não faz parte de transação) ou pode apontar para um objeto que contém informações sobre a transação (e.g., qual o servidor que coordena a transação). 
• Vários threads podem participar de uma mesma transação
• Esses contextos podem ser enviados implicitamente pelo ORB ou explicitamente pelos objetos

• Exemplo de cliente usando transações implícitas (o ORB se encarrega de enviar o contexto para o servidor):
  

  int funcionou = TRUE;
  try {  
      Current::begin(); 
      poupanca.debito(valor); 
      conta_corrente.credito(valor);
      Current::commit();
  }
  catch(TransactionRolledBack) {
      Current::rollback();
      cout << "A transação foi abortada." << endl; 
      funcionou = FALSE;
  }
  catch(...) {
      Current::rollback();
      cout << "Transação falhou." << endl; 
      funcionou = FALSE;
  }
  if (funcionou)
      cout << "Transação foi completada com sucesso. " << endl;
  else
      cout << "Transação foi abortada. " << endl;
  

• Outra possibilidade oferecida por alguns ORBs é localizar a transação corrente via resolve_initial_references:
  

CORBA::Object_var transacao =  
     Bootstrap.resolve_initial_references("TransactionCurrent");
CosTransactions::Current_var transaction_current_oref=
     CosTransactions::Current::_narrow(transacao.in());
transacao->begin();
try {
     minhaConta->transferencia(poupanca, CC, valor);
     ...
     CORBA::Boolean report_heuristics = CORBA_TRUE;
     transacao->commit(report_heuristics);
    }
catch (...) {
// Se a operação falha, execute o rollback e gere a exceção novamente.
// Se o rollback falha, simplesmente gere a exceção original.
try {
     transacao->rollback();
    }
catch (...) {
            log->registra("o roll-back falhou, o mar não está prá peixe");
            }
throw;

• Exemplo de cliente usando transações explícitas:
  // este é um pseudo-código simplificado
  TransactionFactory_var tf = myTraderHelper->locate ("TransactionFactory",
                                                      "TPS > 1000",
                                                      "min(price)");
  Control_var transaction_control = tf->create (10); // 10 segundos
  try {
        a->op1 (transaction_control.in(), ...);
        b->op2 (transaction_control.in(), ...);
        transaction_control->get_terminator()->commit (CORBA_TRUE);
      }
  catch (...) {
        transaction_control->get_terminator()->rollback ();
  }
  

• Antes de ir embora, dê uma olhada no arquivo CosTransactions.idl que contém a definição de todas as interfaces mencionadas acima.
  

Java (não dado em sala de aula)

• Java Transaction Service ( JTS )
• oferece a interface Java: Java Transaction API (JTA) (alto nível)
• implementa o CORBA Object Transaction Service e usa IIOP em sua comunicação interna (baixo nível)
• Exemplo em Enterprise Java Beans, pacote javax.transaction :

public void withdrawCash(double amount) {
           //primeiro pegamos uma referencia para a transacao deste bean
           UserTransaction ut = context.getUserTransaction();

           try {
              ut.begin();
              updateChecking(amount);
              machineBalance -= amount;
              insertMachine(machineBalance);
              ut.commit();
           } catch (Exception ex) {
               try {
                  ut.rollback();
               } catch (SystemException syex) {
                   throw new EJBException
                      ("Rollback failed: " + syex.getMessage());
               }
               throw new EJBException
                  ("Transaction failed: " + ex.getMessage());
            }
}

Referências

• A página do OMG sobre o CORBA Transaction Service
• Orbit's Transactions Page