Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

O primeiro cuidado a se tomar, é evitar um DeadLock. Um sistema está em estado de DeadLock quando existe uma operação (A) fazendo um bloqueio em um registro (L1) e tentando bloquear outro registro (L2) da mesma tabela. Neste mesmo momento existe outra operação (B) bloqueando o registro (L2) e tentando bloquear o registro (L1). Nesta situação não existe como o banco resolver as solicitações, então ele elege, aleatoriamente, uma das conexões e a encerra provocando um erro para o usuário.

...

Note que durante todo o processo, a tabela SC5 está bloqueada e somente é liberada na última transação. Isto é garantido pelo comando CLOSETRANSACTION LOCKIN End Transaction Lockin "SC5", que atualiza a transação, mas mantém o bloqueio do registro para não gerar problemas em outros processamentos concorrentes, conforme informado anteriormente.

Porém, este método como pode ser visto, não garante a total Consistência (aCid) dos dados, uma vez que em caso de queda, a transação apesar de integra, não contém todos os dados informados pelo usuário ou processo. 

 

Outra maneira de resolver ,  é utilizando a função MultLock. Esta função garante o bloqueio de todos os registros de uma mesma tabela. A sua desvantagem é o aumento da serialização do produto. Por este motivo, deve-se  utilizá-la com muito cuidado e ter em mente que sempre há uma alternativa para evitar-se o seu uso.

 

// MultlockSample.prw

If MultLock("SB2",aMults,1)

       Begin Transaction

             // Faz alguma coisa

       End Transaction

EndIf

é manter o mesmo ordenamento (sequenciamento de registros) durante os locks. Porém, esta implementação deve garantir que em todo o sistema, seja utilizada a mesma lógica para o lock desta tabela.

 

A escolha de um dos métodos vai depender do tipo da transação.

...

Transações de formulário devem, obrigatoriamente, seguir o  primeiro exemplo. As transações são mais rápidas e o risco é a atualização parcial do formulário digitado, porém ele estará íntegro. Com certeza o usuário final prefere perder alguns dados a tudo. 

Porém existirão casos em que a atualização parcial não fornece uma transação íntegra. Para estes casos, deve-se  utilizar MultLocko segundo método. Um bom exemplo são as notas fiscais, em que em caso de queda,  o usuário tende a cancelar a nota e refazê-la se houver falta de itens, ou seja, o modelo anterior não traz benefícios ao usuário. Neste exemplo, a ordenação da transação deveria ser por produto+local, visto que a tabela SB2 é atualizada.