Trabalhando com Transações no PostgreSQL

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
 (3)  (0)

O artigo trata da definição do conceito de transações, estados das transações e como o PostgreSQL trabalha com esse conceito. Além disso, demonstra através de um estudo de caso prático como lidar com os principais comandos de transação no PostgreSQL.

Atenção: esse artigo tem uma palestra complementar. Clique e assista!

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

[lead]De que trata o artigo:

O artigo trata da definição do conceito de transações, estados das transações e como o PostgreSQL trabalha com esse conceito. Além disso, demonstra através de um estudo de caso prático como lidar com os principais comandos de transação no PostgreSQL.

Para que serve:

O conteúdo do artigo traz os benefícios de se implementar operações concorrentes no SGBD para que as mesmas não sejam conflitantes e deixem o banco de dados em um estado consistente.

Em que situação o tema é útil:

Essa estratégia é útil quando está sendo desenvolvida qualquer aplicação que tenha acesso a banco de dados e que se necessite prover meios para trabalhar com simultaneidade no acesso aos dados e controle da consistência dos mesmos.[/lead]

O termo transação refere-se a uma coleção de operações que formam uma única unidade de trabalho lógica. Por exemplo, a transferência de dinheiro de uma conta para outra é uma transação consistindo de duas atualizações, uma para cada conta.

Uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados. Para garantir a integridade dos dados, é necessário que o SGBD mantenha as seguintes propriedades das transações: atomicidade, consistência, isolamento e durabilidade.

• Atomicidade: uma transação é uma unidade atômica de processamento; ou ela será executada em sua totalidade ou não será de modo nenhum.

• Consistência: uma transação deve ser preservadora de consistência se sua execução completa fizer o banco de dados passar de um estado consistente para outro também consistente.

• Isolamento: uma transação deve ser executada como se estivesse isolada das demais. Isto é, a execução de uma transação não deve sofrer interferência de quaisquer outras transações concorrentes.

• Durabilidade: as mudanças aplicadas ao banco de dados por uma transação efetivada devem persistir no banco de dados. Essas mudanças não devem ser perdidas em razão de uma falha.

Essas propriedades normalmente são conhecidas como propriedades ACID. Esse acrônimo é derivado da primeira letra de cada uma das quatro propriedades.

Quando se trabalham com transações, é necessário que se faça pelo menos duas ressalvas. A primeira é que em certas situações é interessante se agregar vários comandos como sendo integrantes de uma mesma transação, como, por exemplo, em uma transferência bancária que envolve a retirada de dinheiro de uma conta e o acréscimo em outra como se fosse apenas uma única operação lógica. A segunda ressalva é que em outras situações se faz necessário sacrificar ou flexibilizar as características ACID em virtude da necessidade de maior desempenho.

[subtitulo]Estados de uma Transação[/subtitulo]

Na ausência de falhas, todas as transações são completadas com sucesso. Porém, uma transação nem sempre pode completar sua execução com sucesso. Caso isso ocorra, essa transação é considerada abortada.

Se tivermos que garantir a propriedade de atomicidade, uma transação abortada não pode ter efeito sobre o estado do banco de dados. Assim, qualquer mudança que a transação abortada tenha feito no banco de dados deve ser desfeita. Quando as mudanças causadas por uma transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida (rolled back).

Uma transação que completa sua execução com sucesso é considerada confirmada (committed). Uma transação confirmada que realizou atualizações transforma o banco de dados em um novo estado consistente, que precisa persistir mesmo que haja uma falha no sistema. Quando uma transação tiver sido confirmada, não podemos desfazer seus efeitos abortando-a. A única forma de desfazer os efeitos de uma transação confirmada é executar uma transação de compensação.

Em resumo, uma transação precisa estar em um dos seguintes estados:

• Ativa: é o seu estado inicial. A transação permanece nesse estado enquanto está sendo executada.

• Parcialmente confirmada: é o estado depois que a instrução final foi executada.

• Falha: é o estado depois da descoberta de que a execução normal não pode mais prosseguir.

• Abortada: estado depois que a transação foi revertida e o banco de dados foi restaurado ao seu estado anterior ao início da transação.

• Confirmada: estado após o término bem-sucedido.

A Figura 1 apresenta o diagrama de estado de uma transação.

Figura 1. Diagrama dos estados de uma transação

[subtitulo]Transações no PostgreSQL[/subtitulo]

Diferentemente dos SGBD’s tradicionais, que usam bloqueios para controlar a simultaneidade, o PostgreSQL mantém a consistência dos dados utilizando o modelo multi-versão (Multiversion Concurrency Control, MVCC).

Isto significa que ao consultar o banco de dados, cada transação enxerga um estado do banco de dados, ou seja, como este era há um tempo atrás, sem levar em consideração o estado corrente dos dados subjacentes. Este modelo protege a transação para não enxergar dados inconsistentes, o que poderia ser causado por atualizações feitas por transações simultâneas nas mesmas linhas de dados, fornecendo um isolamento da transação para cada sessão do banco de dados.

"

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?