As soluções RIA do Magic xpa (uniPaaS), como já mencionado em outras oportunidades, estão baseadas sobre o conceito ‘n’ camadas: uma separação clara entre o Server e o Client.
E isso traz novos desafios aos designers de sistemas, especialmente àqueles habituados apenas com as estruturas Desktop (ou OpenClient, ou FatClient).
Quando o usuário (final) de uma aplicação RIA Magic xpa inicia a execução da solução, o Client conecta-se ao Server e várias atividades serão executadas internamente. Dentre elas, duas em especial (objetos do assunto abordado aqui):
- Uma licença, da lista de licenças disponíveis, é alocada (marcada como ocupada).
- Um contexto (ou sessão), que significa uma área reservada de memória e recursos no servidor, é alocada (exclusiva para este usuário).
Quando o usuário encerra normalmente a sua interação com o Client, ou seja, ele fecha o Client através das vias normais, ocorrerá o inverso:
- O contexto para ele criado será liberado (destruído)
- A licença alocada (ocupada) para ele será assinalada como disponível novamente.
Mas nem tudo é sempre normal.
Se o usuário interagir de forma ‘não convencional’, por exemplo, simplesmente desligando o seu dispositivo (ou notebook, ou desktop), o Client não terá chance de informar ao Server que foi finalizado e as liberações necessárias de recursos e licenças não ocorrerão.
Mas não vamos responsabilizar apenas os usuários.
Qualquer falha (energia, comunicação HTTP) de infraestrutura já é suficiente para provocar esta situação.
IMPORTANTE: Observe que isto não é uma adversidade do mundo RIA do Magic xpa, mas de toda estrutura ‘n’ camadas ‘Stateful’.
Para lidar com isso, o Magic xpa inclui em seu arquivo ‘MAGIC.INI’ (na seção [MAGIC_ENV]) uma chave de configuração chamada: ContextInactivityTimeout.
É um parâmetro, expresso em décimos de segundos, que regula o tempo máximo de inatividade de cada contexto (Client conectado). Se o Client ficar mais que este tempo definido sem fazer nenhuma comunicação com o Server (para levar ou trazer informações), seu contexto será liberado automaticamente (e sua licença também).
Se estiver configurado como 36000, por exemplo, qualquer Client que não der sinal de vida em até 1h terá sua sessão eliminada.
Como todo remédio tem seus efeitos colaterais, outra situação pode ocorrer.
Imagine que o usuário está operando normalmente o Client da solução, mas por algum motivo qualquer ficou mais de 1h (considerando o exemplo acima) sem comunicar com o Server.
Quando fizer nova comunicação, será informado que sua sessão foi encerrada e que precisará recomeçar. E isso não é legal 🙂
Eis então a questão:
Se parametrizar o timeOut para um valor muito alto, pode acabar ocupando recursos e licenças por muito tempo, de usuários que não estão mais ativos e que não informaram o seu encerramento ao Server. Se for um valor baixo, pode fazer com que usuários sejam desconectados inadvertidamente, quando não deveriam.
Por isso, vai aqui uma dica.
Não esqueça: é uma dica, e não afirmação de uma verdade única.
Se a preocupação for não alocar recursos (e licenças) mais que o necessário, em ambientes onde a ‘anormalidade’ é bastante esperada, diminua o tempo deste timeOut e obrigue o Client a acessar o Server periodicamente, em intervalos menores que o ContextInactivityTimeout.
Isso pode ser feito através de um ‘Timer’ no MainProgram da aplicação, que execute uma atividade Server Side.
O tráfego entre os lados (Client e Server) aumenta, mas a robustez da solução também.
