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 ...
