DEV Community: josevjunior

Abstraindo o gerenciamento de conexões do banco de dados em uma API Rest com Javalin e seus Handlers

josevjunior — Tue, 21 Sep 2021 00:23:33 +0000

Como os Frameworks abstraem isso?

Quando utilizei o Spring framework pela primeira vez fiquei curioso quando descobri que as classes criadas através dele (Beans) são, por padrão, singleton. Ou seja, a mesma instância de um @Controller por exemplo, é utilizada em toda requisição feita para a url em que ela está mapeada. Minha curiosidade era em saber como ele lidava com o estado dos atributos desses objetos. Em um bean podemos injetar outros objetos como um EntityManager e nesse caso os valores injetados em uma requisição não devem se misturar com os valores de outra. Devem ser Thread-Safe.

Graças a internet consegui encontrar alguém que teve a mesma curiosidade, foi estudar o código-fonte do Spring e escreveu um post sobre que você pode acessar aqui. O artigo tem o foco na utilização do @Repository, mas o princípio é o mesmo.

Em resumo, o Spring cria um proxy para cada Bean criado (Que pode ser um @Service, @Repository ou qualquer outro tipo) e internamente ele salva as propriedades que devem ser Thread Safe em um objeto ThreadLocal. Normalmente objetos com a anotação @PersistenceContext não devem existir em 2 threads(Requisições) diferentes. Então, quando existir uma propriedade com essa anotação em um fonte, o que acessamos é apenas um proxy que dará acesso ao valor pertencente àquela thread. Dessa forma não ocorrerá a situação de um EntityManager existir em duas requisições simultâneas.

Um exemplo bem simples da utilização de um ThreadLocal

O Microframework Javalin

Quando se trata de microframeworks, existem algumas opções que sempre vem a tona como o Vert.x e Spark (Não o Apache Spark). Porém, o microframework que tive contato foi o Javalin, mesmo não sendo o mais completo, possui uma curva de aprendizado muito baixa, é compatível com Kotlin, tem suporte a Websocket e Server Sent Events (SSE), e é extremamente leve.

Dependências necessárias para utilizá-lo

Um simples exemplo esperando uma requisição na porta 7000

Como o Javalin funciona

Quando se cria um novo servidor com o Javalin, é possível usar os chamados Handlers (Semelhante a um callback, listener, observable, etc) que serão responsáveis por tratar as requisições http. Os Handlers geralmente são interfaces de apenas um método com um paramêtro do tipo Context (que é um facilitador de acesso aos métodos da classe HttpServletRequest e HttpServletResponse. Sim, o javalin utiliza a api do javax.servlet e sua implementação é o Jetty). Abaixo um exemplo de como utilizá-los.

O problema com as conexões

Da primeira vez que utilizei o Javalin eu precisava lidar com o operações com banco de dados. Na época eu não optei por nenhuma biblioteca de ORM para facilitar o acesso aos dados ou de injeção de dependência para outros aspectos. O resultado disso foi muito código chato e repetitivo para tratar acesso ao banco e transações como os abaixo:

A situação era ainda pior quando precisava implementar algo muito extenso e com várias etapas. Como um método depende do resultado do outro, para manter tudo na mesma transação era preciso passar a referência da conexão que está sendo usada. Como no exemplo seguinte:

O que poderia ser feito para evitar esse tipo de código?

Depois de entender a premissa de como o Spring trata seus beans em um ambiente multithread, podemos usar as funcionalidades que o próprio Javalin disponibiliza para chegar em um resultado semelhante.

Com o objetivo de usar uma conexão por thread, podemos abstrair a criação, fechamento e rollbacks das conexões no ciclo de vida das requisições do Javalin. Dessa forma, podemos nos concentrar somente na lógica dos métodos de negócio sem a necessidade de passar a referência para todos os métodos que dependem de outro.

Mas, por onde começar?

Vinculando uma conexão do banco de dados a uma thread (que é criada para cada requisição feito por um client). E para isso vamos utilizar a classe ThreadLocal para nos ajudar.

Abaixo temos a classe que será responsável por vincular uma conexão a uma thread. Dessa forma não precisamos nos preocupar com thread-safety na camada de acesso a dados.

Utilizei o hikari CP para o pool de conexões com a base de dados. O arquivo .properties está disponível no repositório do github.

Agora com os handlers que conversam com o ciclo de vida da requisição, é possíveis criar, fechar e desfazer as alterações feitas durante aquela requisição.

Um handler para abrir a conexão a cada requisição
Um Handler para commitar e fechar a conexão após cada requisição
Um handler que irá fazer rollback na transação caso uma exceção especifica seja lançada. (Poderia ser qualquer tipo de exceção)

Para testar tudo isso, vamos fazer um cadastro simples

Uma entidade simples
Um service para acessar os dados
Um controller que chamará o service
Por fim a classe principal que inicializa tudo. Como não precisamos nos preocupar com threads em relação ao acesso a base de dados, os handlers podem usar sempre a mesma instancia do controlador

Conclusão

Esse foi apenas uma demonstração de como é possível utilizar apenas o que o Javalin nos dá para resolver o problema relacionado a gerência de transações/conexões. Claro que poderia ser mais sofisticado utilizando um framework de injeção de dependência ou ORM, mas não era o objetivo do artigo. O código pode ser acessado neste repositório.

Referências

Cache de dados em Java utilizando Proxy Dinâmico e Annotations

josevjunior — Mon, 06 Sep 2021 21:37:24 +0000

Durante o desenvolvimento de uma aplicação vão existir diversos momentos que será necessário implementarmos algum tipo de cache. Seja para diminuirmos acessos à algum serviço externo como um banco de dados ou webservice, ou para evitarmos a criação desnecessária de objetos ditos como "caros". Exemplos comuns desse tipo de objeto são EntityManagerFactory, DataSources, etc...

Normalmente, temos que modificar trechos de código para utilizarmos o cache em algum ponto de nosso sistema. Pode ser que seja apenas um simples if ou uma modificação mais complexa, não iremos escapar de "sujar" nosso código com alguma verificação ou tratamento.

No exemplo abaixo temos uma rotina antes e depois da implementação de cache utilizando um HashMap:

Antes do cache

Depois do cache

Pode parecer uma alteração simples, mas dependendo da quantidade de métodos que precisam ser cacheados, como os métodos estão organizados ou como os valores são salvo no cache, pode se tornar complexo. No exemplo anterior o identificador para acessar os avisos é o próprio código do usuário para qual o aviso foi destinado, mas pode haver outras situações em que precisaremos identificar por usuário e data, ou somente por data. No balanço das horas tudo pode mudar.

Para evitarmos incluir esse tipo de regra de interesse transversal no nosso código, vamos utilizar 2 funcionalidades bastante utilizadas no mundo java: os proxies dinâmicos e as annotations.

Proxy Dinâmico

É uma classe que pode implementar um conjunto de interfaces definidas em tempo de execução e, em cada chamada feita a um dos método dessas interfaces, um despachante será chamado e ficará responsável por definir o comportamento da execução do método. Ou seja, teremos controle do próximo método a ser chamada antes da ação acontecer.

Proxies são muito usados no mundo dos frameworks de injeção de dependências. Pois, como não criamos nossos objetos explicitamente através do comando new, isso dá liberdade para eles, internamente, criarem proxies de nossos objetos adicionando funcionalidades a eles que em um primeiro momento pode parecer mágica, como abrir e fechar uma transação no BD durante a execução de um método ou chamar outro trecho de código que "intercepta" nosso objeto.

Neste exemplos não usaremos o mecanismo de proxy nativo da jdk mas sim um provido pela biblioteca cglib. Através dessa lib não ficaremos presos a utilização de proxy dinâmico apenas em interfaces e poderemos utilizá-los em classes concretas.

Annotations

As annotations ou anotações, por outro lado, não foram feitas para mudar o comportamento de um objeto em tempo de execução, mas sim definir informações(metadados) sobre determinado objeto que podem ser obtidas durante sua execução ou compilação. Podemos ver a utilização das anotações sempre que implementamos o método de uma interface ou sobrescrevemos um método de alguma superclasse.

No caso do @Override, estamos adicionados a informação que o seguinte método está sendo sobrescrito e que não pertence originalmente a essa classe. Tecnicamente isso não altera em nada o comportamento da aplicação, mas através de um proxy é possível verificar se um método, classe, parâmetro ou atributo possui anotações e a partir disso adicionar um comportamento novo de acordo com as informados obtidas.

Implementado nosso cache

Para iniciar, vamos definir nossas annotations e que tipo de informação elas irão nos passar.

Através da anotação Cacheable informaremos qual método gostaríamos de cachear e qual o identificador dele no cache.

Após ter definido o que identificará um método como cacheável, vamos partir para a api responsável por expor os dados cacheados

A classe CacheValue terá o papel de representar um valor cacheado em nossa api, além de conter informações adicionais como a data de criação do valor.

Para consultar ou editar esses valores implementaremos a interface CacheManager

Por ser uma interface ganhamos certa liberdade para definir o mecanismo/engine de armazenamento de dados. Neste exemplo, vamos salvar os dados em um Map. Se quisermos algo mais elaborado, no futuro basta trocar a implementação para usar algo mais "potente" como o Redis ou até mesmo um SGBD.

A implementação do CacheManager que utilizaremos neste exemplo:

Agora vamos ao proxy...

Como dito anteriormente, utilizaremos a cglib para criar proxy's de classes concretas. Para incluir essa dependência em um projeto maven basta adicionar a dependência abaixo no pom.xml

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.2.4</version>
</dependency>

Com essa lib no classpath, implementamos a interface net.sf.cglib.proxy.MethodInterceptor, que contêm o método intercept(Object o, Method method, Object[] os, MethodProxy mp). Ele, como o nome diz, irá interceptar qualquer método cuja chamada for feita pela instancia do proxy. Através da classe Method temos acesso ao método que está sendo executado. Utilizaremos essas informações para saber quais serão cacheados ou não. A classe CacheProxy abaixo mostra toda essa lógica:

O trecho seguinte mostra o método que utilizaremos para criar os proxys. Nele vemos como definimos a classe que será 'proxiada' e como vinculamos o ´MethodInteceptor´.

Utilizando nosso cache

Vamos criar uma classe fictícia responsável por consultar as mensagens disponíveis para cada usuário e definir um de seus método com a anotação @Cacheable

Os valores serão armazenados em estrutura de Map (Chave => Valor) da seguinte forma:

       CHAVE                  VALOR
 ------------   ---
|"USER_MESSAGE"| 1 | => [MENSAGEM_1, MENSAGEM_2]   
 ------------   ---

 -------------- ---
|"USER_MESSAGE"| 2 | => []   
 -------------- ---

O cacheName definido na anotação, em conjunto com os valores dos parâmetros, serão usados como identificadores para salvar o retorno do método em cache. Dessa forma, cada chamada ao método utilizando um valor diferente no parâmetro será um "registro" cacheado.

Alguns testes foram feitos para validar o funcionamento do nosso mecanismo de cache.

set 05, 2021 6:26:22 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Executando método cacheavel: getMessagesOfUser
set 05, 2021 6:26:22 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Consultando valor no cache...
set 05, 2021 6:26:22 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Não foi encontrado nenhum valor no cache. Executando método original...
set 05, 2021 6:26:22 PM br.com.simplecache.service.MessageService getMessagesOfUser
INFORMAÇÕES: Acessando messagens do usuário...
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Salvando retorno no cache...
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Executando método cacheavel: getMessagesOfUser
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Consultando valor no cache...
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Retornando valor cacheado
É a mesma lista: true
set 05, 2021 6:26:23 PM br.com.simplecache.core.SimpleCacheManager removeAll
INFORMAÇÕES: Limpando todo o cache
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Executando método cacheavel: getMessagesOfUser
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Consultando valor no cache...
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Não foi encontrado nenhum valor no cache. Executando método original...
set 05, 2021 6:26:23 PM br.com.simplecache.service.MessageService getMessagesOfUser
INFORMAÇÕES: Acessando messagens do usuário...
set 05, 2021 6:26:23 PM br.com.simplecache.core.CacheProxy intercept
INFORMAÇÕES: Salvando retorno no cache...
É a mesma lista: false

Neste post quis mostrar uma forma de implementar um cache um pouco mais sofisticado, mas sem partir para a utilização de um container CDI, um servidor de aplicação ou migrar para o Spring, já que em sistemas legados não temos tanta liberdade para implementar esse tipo de solução e essa seria um proposta menos invasiva.

Repositório com os fontes: https://github.com/josevjunior/simple-cache-manager