Transações aninhadas e savepoints - Revista SQL Magazine 102

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Este artigo revisa os conceitos básicos e limitações do modelo de Transação Clássico ancorado no protocolo ACID. Deste ponto, descreve duas extensões a este modelo – Transações Aninhadas e Savepoints.

Do que se trata o artigo

Revisa os conceitos básicos e limitações do modelo de Transação Clássico ancorado no protocolo ACID. Deste ponto, descreve duas extensões a este modelo – Transações Aninhadas e Savepoints – que propiciam o controle de tratamento de falhas e a interferência entre operações dentro da própria transação.

Em que situação o tema útil

Grande parte dos sistemas de software emprega a persistência de seus dados em um SBDR. Como toda forma de modificação destes se dá por meio de transações, é fundamental o conhecimento dos conceitos, propriedades e limitações do Modelo Transacional Clássico, bem como de suas extensões.

Resumo DevMan

Transações correspondem às operações de leitura/escrita sobre um SBDR, objetivando atender as necessidades do negócio. Neste artigo, o modelo de Transação Clássico é rememorado e, face as suas limitações, duas extensões são descritas; o modelo de Transação Aninhada e a abstração de Savepoint.

Os Sistemas de Banco de Dados Relacionais – SBDR – alavancaram a capacidade de desenvolvimento de produtos de software mais complexos frente às abordagens anteriores: baseadas no processamento de arquivos do Sistema Operacional ou mesmo em Sistemas de Banco de Dados em Rede e Hierárquico.

Ao encapsular e disponibilizar recursos prontos para a manipulação de dados e suas estruturas, o SBDR isolou os programas dos detalhes de armazenamento dos dados, eliminou a redundância ao suportar múltiplas visões sobre o mesmo dado, bem como ofereceu uma linguagem – o SQL – capaz de trabalhar com os dados de forma declarativa.

A estas capacidades soma-se o seu modelo computacional de processamento e controle de transações que é capaz de entrelaçar diferentes operações de escrita e leitura sobre itens de dados, independentemente do contexto do negócio. Trata-se, portanto, de um modelo de transações genéricas – conhecido como modelo de Transações Clássico ou, popularmente, modelo de Transações ACID (acrônimo das propriedades sustentadas pelo modelo: Atomicidade, Consistência, Isolamento e Durabilidade)– que preserva a consistência dos dados dentro do contexto de um ambiente transacional concorrente mesmo em uma eventual falha de sistema.

No momento em que os SBDRs passam a ser utilizados por aplicações não convencionais – tais como Web Services, Workflow, E-commerce, dentre outras – novos requisitos foram desejados para as transações. Em lugar de transações com curta duração, desprovidas de intercomunicação e canceladas quando da incidência de uma falha – premissas do modelo de Transações Clássico –, a nova demanda requer transações de maior duração, executadas em ambientes heterogêneos, interativas e com maior flexibilidade no tratamento de exceções.

Este cenário levou o aparecimento de extensões ao modelo clássico. Neste contexto, o presente artigo descreverá o modelo de Transações Aninhadas e a abstração de Savepoints que, cada qual a sua maneira, capacitam a transação a decidir qual caminho seguir quando uma exceção ocorrer, isto é, propiciam o rollback seletivo.

Propriedades ACID e o Modelo de Transações Clássico

Antes de abordar diretamente tais extensões, convém estabelecer alguns dos seus fundamentos. Primeiro, é necessário esclarecer um equívoco geral que associa o SBDR como sinônimo de transações. De fato, este conceito se desenvolveu na área de conhecimento de Banco de Dados, pois o SBDR foi capaz de incorporar o protocolo de proteção no processamento de transações, estabelecendo a confiabilidade das operações na incidência de falhas e exceções.

Contudo, além do SBDR, um Sistema de Processamento Transacional – ou simplesmente Sistema Transacional – é formado por componentes responsáveis por interagir junto ao usuário via alguma interface visual e direcionar as requisições destes dentro de uma arquitetura multicamada, como ilustrado na "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?