Introdução

Este artigo apresenta as transações autônomas, um recurso apresentado no DB2 9.7. As transações autônomas são de interesse para administradores de banco de dados e desenvolvedores de aplicativos.

Este artigo trata do DB2 9.7 para Linux, UNIX e Windows. É bom ter conhecimento sobre o processador da linha de comando (CLP) do DB2 e SQL PL.

Para executar os exemplos, é preciso acessar um banco de dados do DB2 9.7 para Linux, UNIX e Windows. Consulte Recursos para fazer o download de uma cópia de avaliação do DB2.

Voltar para parte superior

Descrição básica das transações

As transações são entidades do mundo real que podem ser expressas na forma de texto, números, ou ambos, para serem processadas por um sistema de gerenciamento de banco de dados. São consideradas ações com relação ao banco de dados, e devem ser executadas em grupo.

Por exemplo, uma solicitação para transferir uma quantia X da conta do usuário A para a conta do usuário B é uma transação simples. Essa transação pode ser dividida em duas instruções SQL, como mostra a Listagem 1.

Update table AccountInfo set CurrentBalance = CurrentBalance - X, where UserName=A 
Update table AccountInfo set CurrentBalance = CurrentBalance + X, where UserName=B 
    

Essa transação só pode ser considerada bem-sucedida se ambas as instruções SQL conseguirem atualizar a tabela com sucesso. Para certificar-se de que as duas instruções entrem em vigor, ou nenhuma entre, os aplicativos são executados de modo que não sejam feitas mudanças no banco de dados até que ocorra COMMIT. Em um COMMIT, todas as instruções não confirmadas (instruções após o último COMMIT) entram em vigor juntas, assegurando a integridade de dados. Isso é similar a desligar o comportamento AUTO COMMIT do processador de linha de comandos (CLP), emitir um conjunto de instruções e depois dar um COMMIT manualmente ao terminar. Um ROLLBACK remove todas as mudanças não confirmadas. De modo que as instruções COMMIT e ROLLBACK são blocos de criação importantes de uma implementação de transação.

Voltar para parte superior

Apresentando uma transação autônoma

Uma transação autônoma tem seu próprio escopo de COMMIT e ROLLBACK para assegurar que seu resultado não afete as mudanças não confirmadas do responsável pela chamada. Além disso, os COMMITs e ROLLBACKs na sessão que chama não devem afetar as mudanças finalizadas na conclusão da própria transação autônoma.

Observe que a sessão que chama é suspensa até que a sessão chamada retorne o controle. O suporte a transações autônomas não deve ser encarado de forma alguma como suporte a sessões em execução paralela.

Voltar para parte superior

Criando uma transação autônoma

No DB2, as transações autônomas são implementadas por meio de procedimentos autônomos. Um procedimento armazenado fornece um meio natural de empacotar instruções em um bloco. Para criar um procedimento autônomo, a palavra-chave AUTONOMOUS é especificada na instrução CREATE PROCEDURE, como mostra a Listagem 2.

            
CREATE OR REPLACE your_procedure_name
LANGUAGE SQL
AUTONOMOUS
BEGIN    
	do autonomous work ;
END
    

Quando um procedimento autônomo é chamado, ele é executado dentro da própria sessão para fornecer a independência de transação necessária. Os procedimentos autônomos bem-sucedidos confirmam implicitamente, enquanto os que não são bem-sucedidos retrocedem. Seja como for, a transação que chama fica intacta.

Voltar para parte superior

Analisando um exemplo de uso da vida real

O Banco B quer se certificar de que cada consulta a uma tabela que contém dados confidenciais do cliente seja registrada adequadamente. Para atingir esse objetivo, os desenvolvedores de aplicativos do Banco B recebem um conjunto de interfaces que podem usar para acessar os dados confidenciais. Cada interface é implementada como procedimento armazenado. O procedimento armazenado retorna as informações necessárias da tabela e, ao mesmo tempo, registra o ID do usuário do funcionário que faz a consulta e o número da conta do registro do cliente consultado com a data e hora.

Suposições

O SQL supõe todos os seguintes:

• Que existe conexão com o banco de dados
• Que a confirmação automática está desligada
• Que o terminador da instrução está configurado para % , o que é feito inserindo a instrução CLP do DB2 db2 +c -td% , iniciando uma nova sessão de CLP do DB2

Início

Primeiro, crie as tabelas necessárias. Será necessária uma tabela para conter as informações confidenciais do cliente e outra para conter as informações a serem registradas toda vez que informações confidenciais forem acessadas. A Listagem 3 mostra um exemplo.

            
DROP TABLE customerSensitiveInfo %
CREATE TABLE customerSensitiveInfo(customerAccountNumber integer, amountOverdue integer) %

DROP TABLE log_table %
CREATE TABLE
   log_table(queryingEmployeeID varchar(100), 
             customerAccNumber integer, when timestamp) %
COMMIT %
    

A seguir, crie um procedimento para gravar na log_table quando forem acessadas informações confidenciais, como mostra a Listagem 4.

            
CREATE OR REPLACE PROCEDURE
   log_query (in queryingEmployee varchar(100), 
              in accNumber integer, in when timestamp)
LANGUAGE SQL
BEGIN
   insert into log_table values (queryingEmployee, accNumber, when);
END %
COMMIT %
    

Uma das interfaces que o Banco B fornece aos seus desenvolvedores de aplicativos é um meio de consultar quanto determinada conta está atrasada. O procedimento get_AmountOverdue primeiro faz uma chamada para o procedimento log_query a fim de registrar que acessará dados confidenciais. Depois, faz uma seleção da tabela customerSensitiveInfo para recuperar a quantia atrasada em determinado número da conta. A Listagem 5 mostra um exemplo.

            
CREATE OR REPLACE PROCEDURE
   get_AmountOverdue(in accountNumber integer, out overdue integer)
LANGUAGE SQL
BEGIN
   DECLARE due integer;	
   DECLARE currentTime timestamp;
	
   SET currentTime= CURRENT TIMESTAMP;
	
   CALL log_query(CURRENT USER, accountNumber, currentTime );
	
   SELECT amountOverdue INTO due FROM customerSensitiveInfo 
                         WHERE customerAccountNumber= accountNumber;
									  	 
   SET overdue=due;
END %

COMMIT %
     

Após criar a interface get_AmountOverdue, inclua alguns dados do cliente na tabela customerSensitiveInfo. A seguir, execute a instrução na Listagem 6 para criar a tabela.

            
INSERT INTO customerSensitiveInfo VALUES(12345, 10000),(12346,20000) %
COMMIT %
     

A tabela resultante contém as informações mostradas na Tabela 1.

Com a tabela agora preenchida com dados e um meio de acessá-la, recupere a quantia atrasada da conta 12345. Visto que estamos interessados apenas em visualizar os dados, preferimos fazê-lo de forma anônima. Assim, emita uma instrução de retrocesso imediatamente após a chamada para cobrir seus rastros, como mostra a Listagem 7.

            
CALL get_AmountOverdue(12345, ?) %
        
Value of output parameters
--------------------------
Parameter Name  : OVERDUE
Parameter Value : 10,000
        
return Status = 0
        
ROLLBACK %
    

Verifique o estado da log_table, que é semelhante à Listagem 8.

            
SELECT * FROM log_table %
        
QUERYINGEMPLOYEEID     CUSTOMERACCNUMBER       WHEN
        
0 record(s) selected.
    

Como esperado, a tabela de logs está vazia porque a transação que contém o acesso real à tabela e a inserção na tabela de logs passou por retrocesso. Definitivamente, esse não é o comportamento desejado. Inclua a palavra-chave AUTONOMOUS no procedimento log_query, como mostra a Listagem 9.

            
CREATE OR REPLACE PROCEDURE 
   log_query (in queryingEmployee varchar(100), 
              in accNumber integer, in when timestamp)
LANGUAGE SQL
AUTONOMOUS
BEGIN
   INSERT INTO log_table values (queryingEmployee, accNumber, when);
END %

COMMIT %
    

Agora recupere a quantia atrasada da conta 12345, e retroceda novamente a transação após fazer isso, como mostra a Listagem 10.

            
CALL get_AmountOverdue(12345, ?) %
        
Value of output parameters
--------------------------
Parameter Name  : OVERDUE
Parameter Value : 10,000
        
return Status = 0
        
ROLLBACK %
    

Verifique novamente o estado de log_table, que agora está parecida à Listagem 11.

            
SELECT * FROM log_table %
			 	
QUERYINGEMPLOYEEID     CUSTOMERACCNUMBER       WHEN
98765                  12345                   2009:05:25:12.00.00.000000
			 	
1 record(s) selected.
    

Desta vez, obtém-se o resultado desejado. Embora a mesma transação que leu as informações confidenciais tenha passado por retrocesso, as entradas da log_table foram confirmadas. Dessa forma, pode-se manter um histórico de quem tem acesso aos dados, mesmo que o acesso em si não tenha sido confirmado.

Voltar para parte superior

Conclusão

Este artigo apresentou o conceito de transações autônomas. Agora, entendemos o que é uma transação autônoma e como criar e usar uma no DB2.

Recursos

Aprender

• Use um feed RSS para solicitar a notificação com relação aos artigos futuros desta série. (Descubra mais sobre feeds RSS do conteúdo do developerWorks.)
  
  
• Na área do DB2 para Linux, UNIX e Windows no developerWorks, obtenha os recursos necessários para melhorar suas qualificações no DB2.
  
  
• Encontre informações que descrevem como usar o DB2 no Centro de Informações do DB2 para Linux, UNIX e Windows.
  
  
• Saiba mais sobre Information Management na zona do Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
  
  
• Fique por dentro doseventos técnicos e webcasts do developerWorks .
  
  

Obter produtos e tecnologias

• Faça o download de DB2 Express-C 9.7, uma versão gratuita do servidor de banco de dados DB2 Express.
  
  
• Faça o download de uma versão de avaliação gratuita do DB2 9.7 para Linux, UNIX e Windows..
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira os blogs do developerWorks e participe da Comunidade do developerWorks.
  
  

Sobre os autores

Yash D. Manwani é Associate Software Engineer da IBM India. Trabalha na IBM desde 2008. Desde que ingressou na empresa, ele faz parte da equipe de teste de verificação funcional do DB2 ISL e todo esse tempo ele trabalhou em garantia de qualidade do DB2. Yash é bacharel em engenharia eletroeletrônica e de comunicações pela Universidade de Ciência e Tecnologia de Cochim, na Índia.

Mike Springgay é Senior Development Manager da equipe de desenvolvimento do DB2 para Linux, UNIX e Windows. Ele passou a fazer parte da equipe de desenvolvimento do DB2 em 1997 e atualmente é responsável pelas áreas de conectividade cliente/servidor e de infraestrutura de procedimentos armazenados.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Descrição básica das transações
• Apresentando uma transação autônoma
• Criando uma transação autônoma
• Analisando um exemplo de uso da vida real
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais