Mudanças nos locks e transações na migração de Btrieve para SQL

Dando continuidade a uma série de posts a respeito do uso e configurações de ‘transações’ e ‘locks’ com o Magic xpa, vamos hoje dedicar um tempo especial a um grupo muito importante da comunidade de desenvolvedores Magic: quem está migrando de BTrieve (ISAM) para SQL.

Publicamos um post (ver aqui) com um guia rápido a respeito desta migração.

Agora, vamos falar de um aspecto específico: transações e locks.

O ‘lock’ (ou bloqueio de registro) não é uma novidade para o desenvolvedor. Ele sempre existiu com o BTrieve, e segue existindo também com o bancos SQL:

 

E a sua funcionalidade não muda também.

O que muda são as transações:

Esta configuração, por padrão, não tinha função na execução dos programas pelo runtime Magic xpa. Exceto se o ambiente foi ajustado para executar transações ISAM. Mas via de regra, ele não é (até porque o default da instalação é ISAMTransactions=N). E mesmo que seja (ISAMTransactions=Y), as atividades de transações que o BTrieve pode executar não se comparam as dos bancos SQL.

Mas agora, a coisa muda de figura. Ao se mudar o programa para acessar uma tabela (ou algumas tabelas) SQL ao invés de ISAM (BTrieve), esta configuração passa a ser utilizada pelo runtime Magic xpa.

O por causa disso, programas que não sofreram nenhuma alteração de lógica/programação durante a migração podem passar a se comportar de forma diferente.

E o motivo em geral é sempre o mesmo: registros destas tabelas, que antes não eram bloqueados durante a execução destes programas, agora passarão a ser.

Isso porque no momento em que eles estão sendo acessados, pode haver uma transação de escrita aberta (coisa que não ocorria quando era ISAM). E todos os registros acessados a partir de quando uma transação de escrita foi aberta ficarão bloqueados até que ela seja encerrada (COMMIT ou ROLLBACK).

Esta é uma nova regra, uma nova situação, que você precisa sempre se lembrar.

Claro que um usuário (uma sessão) do sistema não gera problema de ‘lock’ para si mesmo. Quando ele recebe um erro de ‘lock’ e porque outro usuário bloqueou este mesmo registro antes dele, e ele não consegue bloqueá-lo agora.

Mas a pergunta que você vai se fazer é:

“… Antes era executada a mesma rotina, nas mesmas condições, e isso não acontecia …”

Ou

“… Porque este bloqueio, se eu não estou mandando bloquear …”

É verdade. Mas antes não haviam transações abertas na base de dados. E agora há.

Agora, os mesmos registros podem estar sendo acessados em modo exclusivo.

Ou seja: são as transações que estão provocando estes novos (e não programados) ‘locks’.

Não é possível não ter transações quando se está acessando bases SQL. Mesmo que configuremos o programa Magic xpa para não enviar instruções explícitas de BEGIN TRANS, COMMIT e ROLLBACK (ver aqui), o próprio SGBD (ex: Oracle, MSSQL, DB2, etc…) abrirá uma quando receber uma instrução DML (ex: INSERT, UPDATE, DELETE, etc…) que tem a intenção de alterar dados. Assim, mesmo que por um breve espaço de tempo, elas existirão.

Junte a isso também os seguintes fatos:

• Se o programa chamado estiver configurado para não abrir transações (ver acima), mas alguns dos programas que o chamou (hierarquia de execução de programas) já havia aberto uma transação física, este programa que foi chamado muito provavelmente estará dentro desta mesma transação.
• Nós controlamos (pretensamente) no Magic xpa quando uma transação será aberta, mas não quando ela será fechada. O momento de encerramento da transação é decidido pelo runtime, a saber:
  • Ou após o Record Suffix
  • Ou após um Group Suffix
  • Ou após o Task Suffix
• O SGBD pode decidir bloquear (fazer ‘lock’) em mais registros que aqueles que foram acessados durante a transação. O MS-SQL por exemplo, possui uma feature chamada escalonamento de bloqueio, que faz com que ele decida em alguns casos bloquear a tabela inteira que está sendo acessada, por entender que isso será mais eficiente.
• Não existe ‘lock’ numa tabela SQL, sem que haja uma transação ativa. Sua intenção através das configurações pode ser apenas de forçar um ‘lock’ no registro, mas automaticamente será aberta uma transação antes deste ‘lock’. Você não configurou esta transação no programa, mas ela será aberta por causa da configuração da estratégia de lock.

Isso nos alerta para a importância de alguns itens relacionados a migração:

• Testes da Aplicação Final: A aplicação migrada precisa ser exaustivamente testada em todos os seus processos. Verificar se todas as tabelas estão “abrindo” não é o suficiente. Tem de se executar todos os processos, simulando um ambiente real (vários usuários), e observar os resultados. E não são raras as situações em que a decisão correta será mudar a programação e configuração de algumas rotinas, para fugir das novas situações de ‘locks’ que agora passaram a existir.
• Conhecer a Opções de Configurações de Transações/Locks no MAGIC: Não é à toa que existem várias combinações entre Transaction Mode, Transaction Begin e Lock Strategy. Um erro comum entre os desenvolvedores nesta fase de transição, é buscar a “regra para SQL”. Não existe uma regra para se aplicar sempre nos programas. Existe uma opção para cada situação. E seu sistema possui muitas situações diferentes, que consequentemente exigirão configurações diferentes entre os programas.
• Conhecer o SGDB com o qual o você irá trabalhar: O exemplo acima, do MS-SQL, é emblemático. O servidor de dados pode estar bloqueando mais registros do que todas suas configurações na aplicação determinam, simplesmente porque ele acha que deve. Se você se deparar com uma situação assim, e ela é indesejada, não haverá muitas opções além de se alterar a estratégia de programação para evitá-la.

Isso posto, não vamos demonizar as transações. Elas são boas, melhoram a confiabilidade dos dados, todo mundo trabalha com elas, e nós também trabalharemos :).

Nos próximos posts veremos todas as opções de configurações de ‘lock’ e ‘transações’ nos programas Magic xpa, como elas se completam, e como afetam o resultado final da rotina sendo executada.

Fique ligado nesta série.