Programando Java

Facilitando a programação

VRaptor 3 – Poupando recursos – LAZY Dependence Injection

Published on 20 de outubro de 2009

Objetivo: Ao final deste artigo espera-se que você saiba como poupar recursos caros, trazendo eles de forma LAZY, ou como prefiro chamar Just-in-Time (no momento certo).

No VRaptor3 a injeção de dependencia ficou bem mais fácil, os interceptadores que eram os responsáveis para injetar a dependencia sumiram e agora fica tudo a cargo do container, que pode ser o Spring ou o Pico.

A facilidade na injeção de dependencia tem um custo, como não é mais controlado pelo programador que cria o interceptor sempre que declaramos uma dependencia no construtor de um @Component, @Resource ou @Intercepts ele é injetado no inicio, logo na construção, porem as vezes o fluxo de um requisição faz com que não usemos algumas destas injeções de dependencia, disperdiçando recursos valiosos.

Por exemplo, vamos supor o seguinte @Resource abaixo, que cadastra produtos

  1. import java.util.List;
  2.  
  3. import org.hibernate.Session;
  4.  
  5. import br.com.caelum.vraptor.Result;
  6. import br.com.caelum.vraptor.view.Results;
  7.  
  8. public class ProdutoController {
  9.         /**
  10.          * O recurso que queremos poupar.
  11.          */
  12.         private final Session session;
  13.         private final Result result;
  14.        
  15.         public ProdutoController(final Session session, final Result result) {
  16.                 this.session = session;
  17.                 this.result = result;
  18.         }
  19.        
  20.         /**
  21.          * apenas renderiza o formulário
  22.          */
  23.         public void form() {}
  24.        
  25.         public List<Produto> listar() {
  26.                 return session.createCriteria(Produto.class).list();
  27.         }
  28.        
  29.         public Produto adiciona(Produto produto) {
  30.                 session.persist(produto);
  31.                 result.use(Results.logic()).redirectTo(getClass()).listar();
  32.                 return produto;
  33.         }
  34. }

Sempre que alguem faz uma requisição a qualquer lógica dentro do recurso ProdutoController uma Session é aberta, porem note que abrir o formulário para adicionar produtos não requer sessão com o banco, ele apenas renderiza uma página, cada vez que o formulário de produtos é aberto um importante e caro recurso do sistema esta sendo requerido, e de forma totalmente ociosa.

Como agir neste caso ? isolar o formulário poderia resolver este problema mais recairia em outro, da mantenabilidade.

O ideal é que este recurso só fosse realmente injetado no tempo certo (Just in Time) como seria possivel fazer isso ? a solução é usar proxy dinamicos, enviando uma session que só realmente abrirá a conexão com o banco quando um de seus métodos for invocado

  1. import java.lang.reflect.Method;
  2.  
  3. import javax.annotation.PreDestroy;
  4. import org.hibernate.classic.Session;
  5. import org.hibernate.SessionFactory;
  6.  
  7. import net.vidageek.mirror.dsl.Mirror;
  8.  
  9. import br.com.caelum.vraptor.ioc.ApplicationScoped;
  10. import br.com.caelum.vraptor.ioc.Component;
  11. import br.com.caelum.vraptor.ioc.ComponentFactory;
  12. import br.com.caelum.vraptor.ioc.RequestScoped;
  13. import br.com.caelum.vraptor.proxy.MethodInvocation;
  14. import br.com.caelum.vraptor.proxy.Proxifier;
  15. import br.com.caelum.vraptor.proxy.SuperMethod;
  16.  
  17. /**
  18.  * <b>JIT (Just-in-Time) {@link Session} Creator</b> fábrica para o componente {@link Session}
  19.  * gerado de forma LAZY ou JIT(Just-in-Time) a partir de uma {@link SessionFactory}, que
  20.  * normalmente se encontra em um ecopo de aplicativo @{@link ApplicationScoped}.
  21.  *
  22.  * @author Tomaz Lavieri
  23.  * @since 1.0
  24.  */
  25. @Component
  26. @RequestScoped
  27. public class JITSessionCreator implements ComponentFactory<Session> {
  28.        
  29.     private static final Method CLOSE = new Mirror().on(Session.class).reflect().method(“close”).withoutArgs();
  30.     private static final Method FINALIZE = new Mirror().on(Object.class).reflect().method(“finalize”).withoutArgs();
  31.     private final SessionFactory factory;
  32.     /** Guarda a Proxy Session */
  33.         private final Session proxy;
  34.         /** Guarada a Session real. */
  35.         private Session session;
  36.        
  37.         public JITSessionCreator(final SessionFactory factory, final Proxifier proxifier) {
  38.                 this.factory = factory;
  39.                 this.proxy = proxify(Session.class, proxifier); // *1*
  40.         }
  41.        
  42.         /**
  43.          * Cria o JIT Session, que repassa a invocação de qualquer método, exceto
  44.          * {@link Object#finalize()} e {@link Session#close()}, para uma session real, criando
  45.          * uma se necessário.
  46.          */
  47.         private Session proxify(Class<? extends Session> target, Proxifier proxifier) {
  48.                 return proxifier.proxify(target, new MethodInvocation<Session>() {
  49.                     @Override // *2*
  50.                     public Object intercept(Session proxy, Method method, Object[] args, SuperMethod superMethod) {
  51.                         if (method.equals(CLOSE) || (method.equals(FINALIZE) && session == null)) {
  52.                             return null; //skip
  53.                         }
  54.                         return new Mirror().on(getSession()).invoke().method(method).withArgs(args);
  55.                     }
  56.                 });
  57.         }
  58.        
  59.         public Session getSession() {
  60.                 if (session == null) // *3*
  61.                         session =       factory.openSession();
  62.                 return session;
  63.         }
  64.        
  65.         @Override
  66.         public Session getInstance() {
  67.                 return proxy; // *4*
  68.         }
  69.        
  70.         @PreDestroy
  71.         public void destroy() { // *5*
  72.                 if (session != null && session.isOpen()) {
  73.                         session.close();
  74.                 }
  75.         }
  76. }

Explicando alguns pontos chaves, comentados com // *N*

  1. O Proxfier é um objeto das libs do vrapor que auxilia na criação de objetos proxys ele é responsável por escolher a biblioteca que implementa o proxy dinamico, e então invocar via callback um método interceptor, como falamo abaixo.
  2. Neste ponto temos a implementação do nosso interceptor, sempre que um método for envocado em nosso proxy, esse intereptor é invocado primeiro, ele filtra as chamada ao método finalize caso a session real ainda não tenha sido criada, isso evita criar a session apenas para finaliza-la.
    O método close também é filtrao, isso é feito para evitar criar uma session apenas para fecha-la, e também por que o nosso SessionCreator é que é o responsavel por fechar a session ao final do scopo, quando a request acabar.
    Todos os outros métodos são repassados para uma session através do método getSession() onde é realmente que acontece o LAZY ou JIT.
  3. Aqui é onde acontece a mágia, da primeira vez que getSession() é invocado a sessão é criada, e então repassada, todas as outras chamadas a getSession() repassam a sessão anteriormente criada, assim, se getSession() nunca for envocado, ou seja, se nenhum método for envocado no proxy, getSession() nunca será invocado, e a sessão real não será criada.
  4. O retorno desse ComponentFactory é a Session proxy, que só criará a session real se um de seus métodos for invocado.
  5. Ao final do escopo o destroy é invocado, ele verifica se a session real existe, existindo verifica se esta ainda esta aberta, e estando ele fecha, desta forma é possivel garantir que o recurso será sempre liberado.

Assim podemos agora pedir uma session sempre que acharmos que vamos precisar de uma, sabendo que o recurso só será realmente solicitado quando formos usar um de seus métodos, salvando assim o recurso.

Esta mesma abordagem pode ser usada para outros recursos caros do sistema.

Os códigos fonte para os ComponentFactory de EntityManager e Session que utilizo podem ser encontrados neste link: http://guj.com.br/posts/list/141500.java

Filed under: Hibernate, Java, VRaptor, VRaptor3
Tags: , , , , , , , ,

Deixe uma resposta

« VRaptor3 – Interceptando recursos anotados