Single Record Cache

Quando estamos desenvolvendo é bom ter em mente o impacto do código que estamos escrevendo em termos de performance do banco de dados. A infraestrura de acesso a dados do Ax permite que o AOS faça o caching de registros pesquisados no banco de dados, diminuindo assim as idas e voltas no banco de dados.


Independente da opção de cache o AOS somente faz o cache do registro quando o select utiliza TODAS as chaves presentes na primary index da tabela e somente se o operador == for utilizado em todas elas, pois o AOS faz o cache de um registro por vez, isto significa que >, <, != não tem efeito nenhum sobre o cache.


Toda vez que o modificador forUpdate é utilizado, caso não tenha sido utilizado previamente na mesma transação, o AOS atualiza o cache.


Como o Ax trabalha com o cache depende da propriedade da tabela chamada CacheLookup. As seguintes opções estão definidas:
1. None - sem cache
2. Found
3. FoundAndEmpty
4. NotInTTS
5. EntireTable


Utilizando Found and FoundAndEmpty o cache é preservado depois do uso do ttsBegin, ttsCommit e ttsAbort.


A opção FoundAndEmpty contém mais um detalhe, caso um select não devolva nenhum resultado, isto é, o registro com aquela PK não existe no banco, aquela PK é marcada como cacheada todos os selects subsequentes são "lidos" do cache e o cache é atualizado somente quando forUpdate seja chamado.


Utilizando NotInTTS o cache é atualizado no primeiro select após o ttsBegin.


A opção EntireTable somente deve ser utilizada para tabelas que não são atualizadas com frequência, como tabelas de parametros, grupos, etc, pois o AOS faz um cache completo da tabela quando a tabela for lida pela primeira vez, o AOS então cacheia a tabela toda do servidor, quando um client le a tabela cacheada no AOS ele envia a linha cacheada para o client sem ir ao banco de dados.


O AOS faz um flush do cache toda vez que um update, delete ou insert é feito na tabela, ela volta a ser toda cacheada na próxima vez que for lida.


O join entre tabelas com esse tipo de cache com tabelas que não tem o tipo de cache EntireTable sempre força o AOS a atualizar o cache não importa o momento do select.

Procurem sempre utilizar os métodos Find e Exists das tabelas pois eles sempre são escritos utilziando a PK da tabelas e garantem o uso do cache para aquela tabela.

Utilizando essas poucas regras e tendo elas em mente quando estão desenvolvendo para seus clientes, sempre tentem verificar se o modo que estão acessando o banco de dados pode ou não afetar a performance geral da fucnionalidade que estão desenvolvendo.

Até a próxima.