Bancos de Dados — Por que usar transações curtas ?

Antes de mais nada, vamos contextualizar o que é uma “transação”: Damos o nome de transação a uma mudança protegida de estado de uma ou mais informações de múltiplas linhas (ou registros) em uma ou mais tabelas de um Banco de Dados, que garanta apenas dois resultados possíveis: Todas as alterações foram realizadas, ou nenhuma foi realizada.

Se a aplicação, função ou processo em questão apresentar qualquer erro, e desconectar do banco de dados antes de confirmar a transação, o banco de dados cancela a transação, e nenhuma inserção, alteração ou exclusão de dados feita desde o momento que a transação foi iniciada por aquele processo será gravado (ou “persistido) na(s) tabela(s) envolvida(s) no processo.

A aplicação também pode intencionalmente solicitar ao banco de dados o cancelamento da transação em andamento. O encerramento de uma transação mediante confirmação é conhecido pelo termo “COMMIT”, e o cancelamento da transação sem efetivar as alterações é conhecido por “ROLLBACK”.

Então, por que transações curtas ?

Uma vez que um processo abra uma transação, e comece a mexer nos dados, a alteração de uma informação/campo (ou coluna) de uma tabela no mínimo gera um bloqueio exclusivo naquele registro (ou linha) da tabela, e esse bloqueio somente é liberado quando a transação é confirmada e/ou cancelada, e enquanto este bloqueio existir, ele impede que qualquer outro processo consiga realizar uma alteração na(s) linha(s) com atualizações em andamento.

Isso pode gerar retenção em pontos do sistema que concorram pela atualização dos mesmos registros, gerando um efeito em cascata de “enfileiramento” de processos em espera por um bloqueio exclusivo, ou dependendo da ordem de obtenção de bloqueio dos registros, isso pode levar o banco de dados a uma situação de “beco sem saída” — foi a melhor tradução que eu encontrei para “DEADLOCK”.

Quanto maior a transação, mais pesada fica a sua confirmação e seu cancelamento. E, se uma transação for cancelada, todos os dados inseridos e/ou atualizados até aquele momento desde o início da transação é “jogado fora”.

Por isso, deve-se evitar o uso intencional de um “ROLLBACK” explicito pela aplicação. Procure sempre validar os dados antes de inserir ou alterar, para que um ROLLBACK seja realizado apenas implicitamente, em caso de erro no processo, e somente inicie a transação quando os dados já foram pré-validados, e você já tem na mão todas as informações para persistir no banco de dados.

Curiosidades

As aplicações escritas usando a linguagem AdvPL e a tecnologia do TOTVS Application Server, realizam o acesso a bancos de dados relacionais através de uma aplicação intermediária chamada de DBACCESS. Ele encapsula o acesso a dados relacionais, e emula o acesso de consulta e manutenção de dados das aplicações AdvPL escritas para trabalhar com um modelo de acesso a dados ISAM (Método de acesso sequencial indexado), e possui controles próprios de bloqueio e identificação de DEADLOCK, entre outras funcionalidades deveras interessantes 😁

Para mais informações sobre AdvPL , DBACCESS, e demais componentes da plataforma de desenvolvimento TOTVSTEC, consulte o portal da TDN — Totvs Developer Network, no link https://tdn.totvs.com/display/tec/TOTVSTEC