Definições de compatibilidade – Transacções aninhadas (Parte 3)

Bem-vindo à nossa série em curso sobre configurações de compatibilidade e características “ocultas” para um melhor desempenho. No primeiro post, analisámos o comando QUERY BY FORMULA e o seu impacto no comportamento de uma aplicação. O segundo post foi sobre a opção de compatibilidade“Use period and comma as placeholders” para evitar correr para “os números são exibidos como >>>>>>>>>” .

Nesta terceira parcela, vamos explorar as Transacções Aninhadas.

Se esta opção não for visível na sua página de Compatibilidade (porque criou a sua estrutura com 4D v11 ou posterior) ou já estiver activada, não há necessidade de ler mais. Se este não for o caso, a sua aplicação está a correr num modo que emula o 4D v2004. Não só está a perder muitas das grandes características, como também está numa posição de risco, uma vez que este modo já não é testado por 4D.

Quando 4D introduziu as primeiras transacções há 25 anos atrás, só suportava um único nível de transacção: as operações ou estavam numa transacção ou não estavam. Contudo, há mais de 10 anos que o 4D tem apoiado transacções de vários níveis (aninhadas). Deve tirar partido delas!

Se nunca utilizou transacções, aconselho-o a ler este post no blogue sobre transacções… caso contrário, continue a ler!

Bandeira de compatibilidade de Transacções aninhadas

Então, porque é que existe uma opção? Não é melhor utilizar sempre transacções aninhadas?

Sim, é muito melhor. No entanto, o seu código existente pode ter sido escrito apenas com transacções de um único nível, sendo assim a opção.

START TRANSACTION
START TRANSACTION // second call by accident, ignored from 4D v2004
VALIDATE TRANSACTION // v2004 was now at the end, no transaction running anymore
// v11 still has a transaction open…

Porquê? O que poderia acontecer? Ainda bem que perguntou!! Digamos que um utilizador final abandona uma aplicação com apenas transacções de um nível, que pode ainda ter transacções não confirmadas, não validadas, abertas. Serão automaticamente canceladas e todo esse trabalho poderá ser perdido!

Antes de activar a bandeira de compatibilidade de transacções aninhadas, deverá rever cuidadosamente o seu código e certificar-se de que todas as chamadas para transacções são equilibradas. Verifique se não só estão abertas, mas também fechadas. Por exemplo, um método chamado dentro de uma condição IF poderia iniciar uma transacção, mas poderia ser difícil de encontrar se o código não estiver bem estruturado e organizado.

Há duas maneiras de verificar isto:

1. A primeira é fazer uma auditoria completa do código, que poderia ser muito demorada. No entanto, existe outra opção.
2. Se a sua aplicação utilizar apenas um processo, poderá ser muito simples. No evento On Exit, verifique se ainda existem transacções em aberto. Se sim, informe (envie a si próprio um e-mail, telefone ao administrador, etc.) E valide a transacção (assumindo que foi uma transacção aberta por acidente).

Uma vez que, muito provavelmente, terá mais processos, terá de os identificar. Se tem um método genérico que chama em qualquer processo quando o inicia ou termina, não se preocupe. Caso contrário, terá de encontrar estes processos e modificar cada um deles. No final de cada processo, verifique o Transaction level.

Nesta altura, não faça mais nada. Antes de começar a utilizar as transacções aninhadas, verifique o seu código!

suspensão de Transacções

Assim que tiver activado as transacções aninhadas, notará outro benefício. Pode carregar no botão “snooze”!

Digamos que está dentro de uma transacção e precisa de aumentar um contador armazenado noutra tabela(por exemplo, um número de factura). Desde que a transacção seja aberta, todos os registos modificados são bloqueados para que outros utilizadores ou processos não os possam modificar. Embora isto possa ser suficiente para a factura em si, não é tão bom para o contador de números de facturação. No passado, os criadores tentaram contornar esta questão, iniciando outro processo e criando processos para lidar com a comunicação. Isso é muito código apenas para executar algo fora de uma transacção. Felizmente, há uma maneira melhor… assim que as transacções aninhadas são activadas, é possível fazer uma pausa a qualquer momento . Isto permite-lhe incrementar o contador e retomar a transacção.

Esta é uma característica tão fantástica que há um artigo inteiro na documentação sobre a mesma!

Memória

Quer esteja a utilizar ou não transacções aninhadas, deve estar ciente de que as transacções aumentam a memória necessária porque os dados modificados são armazenados num buffer temporário. Não só isso, mas internamente 4D também constrói índices temporários que permitem a execução de consultas.

Como resultado, quanto maiores forem as suas tabelas (à medida que mais campos são indexados e mais registos são modificados), mais memória é necessária. Se a sua memória for insuficiente, verá ficheiros temporários criados ao lado dos seus ficheiros .4DD (para armazenar o buffer temporário). Estes ficheiros, ao mesmo tempo que resolvem a falta de memória, podem diminuir o desempenho da sua aplicação.

Assim, embora as transacções sejam óptimas, não é a melhor ideia manipular milhões de registos dentro de um único!