Trabalhando com ‘locks’ com o Magic xpa

Dando continuidade a uma série de posts a respeito do uso e configurações de ‘transações’ e ‘locks’ com o Magic xpa (ver o anterior), vamos hoje ver especificamente sobre as configurações de locks.

O lock é um conceito relativamente mais simples que a transação.

Consiste no ato de “bloquear exclusivamente o acesso a um ou mais registros de dados”, durante um determinado tempo. O lock só é concedido a um usuário por vez.

A famosa mensagem do Magic xpa runtime: linha alocada (ou locked record), significa justamente que o usuário atual está tentando obter o lock a um dado, mas este lock já foi concedido a outro usuário que ainda não liberou (finalizou) o lock recebido.

Existe material razoavelmente abrangente sobre este tema na Developer Community, mas vamos tentar resumir os pontos principais neste post.

A) O lock é selecionado na aba “Data” das configurações tarefa:

B) O lock é uma configuração exclusiva das tarefas On-Line e Batch. Tanto que se selecionarmos o tipo da tarefa como Rich Client ou Browser Client, esta opção muda automaticamente para ‘No Lock’ e fica desabilitada.

C) No Magic xpa, nós escolhemos quando o lock deve iniciar, e o Magic Runtime decide quando ele deve terminar. Por exemplo:

a) No Lock: nossa intenção é dizer ao Magic Runtime que não desejamos fazer lock de dados durante a execução desta tarefa.
b) Immediate: estamos dizendo ao Magic Runtime que desejamos iniciar o lock de dados logo após ele serem carregados da base, antes do Record Prefix.
c) On Modify: estamos dizendo ao Magic Runtime que desejamos iniciar lock de dados no momento em que houver uma tentativa de mudança dos dados carregados da base, seja interativa (através da ação do usuário) ou sistêmica (instrução Update). Isso pode acontecer durante o Record Prefix, durante o Record Loop (antigo Record Main), ou durante o Record Suffix. E pode ser que nunca ocorra, se não houver ação de alterações. No caso de não haver a alteração de dados, o lock não é iniciado.
d) Before Update: estamos dizendo ao Magic Runtime que desejamos iniciar lock de dados antes da atualização dos conteúdos alterados, na base. Isso ocorre após Record Suffix.

Em qualquer do três casos acima (b, c ou d), o Magic xpa decide quando irá liberar o lock concedido. E isso, pode ser:

• Após a atualizações dos conteúdos alterado, na base. Isso ocorre após Record Suffix.
• Quando for recebido um evento Cancel.

Estas são as regras gerais.

Agora vamos ao detalhes.

Como visto nos post anteriores, os locks estão ligados as transações. Como consequência, os momentos de início e fim do lock podem ser alterados indiretamente. Por exemplo, se o lock estiver como On Modify, mas a transação da tarefa estiver como Physical – Before Task Prefix

O registros acessados começarão a ser bloqueados (lock) logo após a transação ser aberta, que é antes do Task Prefix, e não apenas numa tentativa de alteração. Da mesma forma, neste mesmo cenário, o lock só seria liberado após o fechamento da transação, que é após o Task Suffix, e não após a atualização dos conteúdos alterados.

É importante ter sempre em mente esta relação entre as duas configurações, pois uma interfere na outra.

Outro coisa muito importante, é compreender o contexto da execução do programa/tarefa.

Nós podemos configurar uma tarefa “A” que acessa dados, para não iniciar transação e também não iniciar locks. Porém, durante a execução real do sistema esta tarefa “A” pode ser acionada por uma outra tarefa “B”, que já havia iniciado uma transação ou lock antes desta chamada. Logo, os dados acessados na tarefa “A” também estarão sendo transacionados ou bloqueados (lock), mesmo que sua configuração esteja explicitando o contrário. Não basta avaliar apenas as configurações da tarefa “A”, mas também as configurações de todas as tarefas que compõem a Pilha de Chamada, pois a configuração da tarefa anterior interfere na execução da próxima tarefa.

Quando o Magic xpa Runtime vai realizar um início de lock, ele faz isso apenas para as tabelas assinaladas (configuradas) com acesso de escrita (intenção de alteração). Os dados das tabelas configuradas com acesso de leitura apenas (intenção de não alteração), ficam de foram do processo de lock. Isso é uma questão relevante, pois se estivermos acessando dados de tabelas apenas para “consultar” registros (sem intenção de alterá-los), assinalá-las como apenas leitura ajuda a evitar locks desnecessários.

Se o Magic xpa Runtime conseguir obter todos os locks necessários, o sistema continua normalmente. Se não conseguir, entram em ação o Error Behavior Strategy da tarefa e os Errors Handlers, o que estiver disponível no momento.

Para finalizar, existem dois tipos de locks no Magic xpa: físico e lógico.

No físico, o registro é realmente bloqueado na base de dados. Este é o sistema padrão de lock para todos os bancos com gateways nativos (Oracle, MSSQL, MySQL, etc…).

No lógico, o registro não é bloqueado na base de dados, mas ao invés disso, antes de atualizar os dados é feita uma checagem para saber se aquele registro ainda existe e não foi alterado. Se a resposta do teste for “sim”, a atualização é efetuada. Se for “não”, um erro de “registro alterado por outro usuário” é gerado e a atualização falha. Este é o sistema padrão de lock para todos os bancos com gateways ODBC.

Nos próximos posts veremos todas as opções de configurações de ‘transações’ nos programas Magic xpa.

Fique ligado nesta série.