Melhorando Performance de JPA com Spring Web Flow

No TDC2009 realizado pela Globalcode em São Paulo eu apresentei um Lightning Talk sobre um problema específico de performance em aplicações Web com JPA e uma possível solução usando o Spring Web Flow.

Num período de 15 minutos, os slides a seguir foram apresentados e seguidos de alguns vídeos de demonstração de uma aplicação Web em execução.

Melhorando performance do JPA com Spring Web Flow

View more presentations from Dr. Spock.

Nesta apresentação foi dito que temos encontrado problemas de performance em aplicações Web que utilizam as tecnologias JSF + JPA + Ajax quando precisamos gerenciar um contexto de persistência (EntityManager). Este problemas se manifestam quando aplicamos uma resposta errada para a pergunta: Como gerenciar o contexto de persistência numa aplicação Web?

Se as aplicações não usam Ajax e limitam-se ao modelo orientado a requisições, a solução mais comum é o uso do design pattern chamado "Open Session In View Filter". Através deste design pattern, um contexto de persistência novo é aberto no início de uma requisição Web através de um filtro e fechado ao final desta requisição pelo mesmo filtro. Durante o processamento da requisição, as entidades persistente carregadas não geram erros (LazyInitializationException, por exemplo) porque o contexto de persistência ainda esta aberto. Mas se estas entidades são armazenadas no escopo de sessão, muitos erros podem acontecer quando estes objetos são usados numa outra requisição. Para resolver estes erros, muitos desenvolvedores utilizam o artifício de navegar nas associações, ou reinserir (merge) as entidades no novo contexto de persistência ou recarregar/salvar várias vezes estas entidades. Estas implementações degradam consideravelmente a performance da aplicação, além de inviabilizar o uso efetivo de cache de objetos, normalmente encontrado nas implementações de JPA.

O problema de performance é agravado quando a aplicação usa intensamente o modelo orientado a eventos. Este modelo é a tendência natural dos sistemas Web 2.0, principalmente pela mudança de paradigma de desenvolvimento Web proporcionado pelo JSF e Ajax. Ao longo de uma sessão de uso da aplicação e acesso às telas, muitas requisições assíncronas são enviadas para a aplicação no lado do servidor. A cada requisição, um novo contexto de persistência é aberto e fechado se o design pattern sugerido anteriormente é aplicado. Portanto, a resposta para a primeira pergunta não é o uso deste design pattern e muito menos os "workarounds" para os efeitos colaterais resultantes do uso deste padrão no novo modelo orientado a eventos.

Uma solução proposta e aplicada na prática está baseada no uso do conceito de escopo de conversação. Um escopo numa aplicação web define uma visibilidade e um tempo de vida dos objetos armazenados no servidor. Atualmente, um contâiner Web implementa os escopos de página, requisição, sessão e aplicação. O JSF 1.2 usa estes mesmos escopos e o JSF 2.0 adiciona os escopos View e Custom (que permite a criação de novos escopos). Já o Spring Framework disponibiliza os escopos singleton, prototype, request e session. Contudo, nenhum destes escopos tem a visibilidade por usuário e, ao mesmo tempo, o tempo de vida entre uma requisição e uma sessão como requerido pelo escopo de conversação. Mas, os frameworks Spring Web Flow, Seam Framework e Apache MyFaces Orchestra implementam este escopo e permitem o gerenciamento automático de um contexto de persistência neste escopo.

Então, uma solução efetiva para os problemas de performance e erros numa aplicação que usa JPA e o modelo orientado a eventos é o uso do escopo de conversação implementado por um dos frameworks sugeridos. Na aplicação web a ser demonstrada foi escolhido o Spring Web Flow por ser um dos produtos do Spring Portifolio, utilizar as mesmas boas práticas do Spring Framework, ter um baixo risco de se tornar um produto descontinuado e ser fácil de integrar numa arquitetura já baseada no Spring Framework + JSF + JPA.

O uso do Spring Web Flow (SWF) permitiu o fim dos erros de LazyInitializationException, o uso efetivo de cache das entidades persistentes, redução da quantidade de objetos na sessão, suporte a paginação, filtro e ordenação já na camada de apresentação com uma forte integração com o mecanismo de persistência JPA. Contudo, o SWF na versão atual (v.2) ainda requer o uso de XML para determinar quando uma conversação é iniciada e quando será destruída. Além de ser necessário realizar um "merge" das entidades ao final da conversação para atualizar na base de dados as possíveis alterações em memória.

Os vídeos de demonstração a seguir ilustram o funcionamento da uma aplicação web realizada através de uma implementação de referência que usa Spring Framework 2.5, JSF 1.2, JPA 1.0, Richfaces 3.3, Facelets 1.1.15, Spring Web Flow 2.0, Hibernate (JPA Provider) e MySQL 5.0.

TDC2009 Video Demo 1


TDC2009 Video Demo 2


TDC2009 Video Demo 3


Este último vídeo demonstra o poder do Lazy Loading a medida que os painéis são abertos e fechados. Como o contexto de persistência permanece disponível durante o período do escopo de conversação aberto, tornou-se possível carregar da base de dados somente alguns objetos e depois os outros objetos a medida que os painéis são expandidos. Os logs apresentados através do NetBeans neste vídeo ilustram a carga sob demanda dos objetos. Também ilustra o uso do cache nos objetos já carregados quando painéis que já foram expandidos são abertos novamente. Neste caso, nenhum log de consulta ao banco de dados aparece no NetBeans.

O TDC2009 em São Paulo foi fantástico!
By Spock

JBoss Seam: Injection vs Outjection

Injection - A capacidade do JBoss Seam de atribuir uma referência válida para um objeto (Seam Component) num atributo de outro componente. Esta capacidade é realizada através das anotações @In e @DataModelSelection, por exemplo. Quando o Seam encontra estas anotações num atributo de um Seam Component, localiza um objeto num dos contextos com o nome indicado e injeta no atributo.

Outjection - Que também podemos chamar de ejeção, é a capacidade do JBoss Seam de expor um objeto referenciado por um atributo de um Seam Component num dos contextos do Seam. Ejetar significa o Seam pegar a referência para um objeto armazenado num atributo privado de um Seam Component e armazenar num dos contextos com um nome associado. Ao expor o atributo, mesmo privado, este estará disponível para injeção em outros Seam Components via injection ou para acesso via Expression Language (EL) numa tela JSF. Esta capacidade é realizada pelo Seam através da anotação @Out. Contudo, no momento de ejetar um atributo como Seam Component num dos contextos, o Seam pode realizar alguma transformação do objeto como, por exemplo, na anotação @DataModel onde o Seam encapsula uma lista de objetos num JSF Data Model antes de armazená-lo no contexto. Assim, quando o usuário seleciona um item num Data Table numa tela JSF, o JSF sabe qual objeto foi selecionado e o Seam recupera este objeto para injetar num outro atributo do Seam Component que foi marcado com a anotação @DataModelSelection.

Sobre os contextos do Seam escrevi os posts Sobre os contextos do JBoss Seam e Seam Contexts Ilustrados. Neste último post cito a diferença entre Context Variable e Instance Variable. Considerando estes dois conceitos, podemos definir como injeção o movimento realizado pelo Seam de uma referência para um objeto do Context Variable para o Instance Variable. Já ejeção significa o movimento de um Instance Variable para um Context Variable. Nestes movimentos, o Seam pode realizar transformação dos objetos.

• Anotações que realizam injeção: @In e @DataModelSelection.
• Anotações que realizam ejeção: @Out, @DataModel, @Factory e @Name.

Then, any issue let me know! Post comments!

Integrando o futuro: Seam e Spring

Quem disse que não é possível usar o Spring Framework e o JBoss Seam juntos?

No JustJava2008 apresentei uma palestra com o resultado da integração destes dois frameworks. Nesta apresentação ilustrei os passos necessários para configurar uma aplicação Web para ter os dois frameworks funcionando em conjunto. Apresentei as características do Seam que o qualificam para o gerenciamento da camada de apresentação (View e Controller) numa arquitetura MVC na Web com Ajax e as características do Spring que o qualificam para o gerenciamento da camada model com integração com os serviços EE (transação, segurança, logging, remoting, pooling, etc). Claro que estes frameworks são mais abrangentes do que o discutido na palestra.

Na apresentação pude discutir os problemas encontrados nesta integração considerando as diferenças destes frameworks que resultam em alguns curto-circuitos. Contudo, a integração até que funciona bem! Mas, tem que ficar atento com estes curtos.

A seguir estão os slides para a comunidade. Then, enjoy it!

Integracao Seam Spring

Sobre os contextos do JBoss Seam

O primeiro passo para entender o conceito de bijeção (bijection) do JBoss Seam é compreender muito bem os contextos Web e os próprios contextos do JBoss Seam.

Os contextos do Seam são muito semelhantes aos contextos de uma aplicação Web baseado em Java EE (componentes Servlet e JSP). Os contextos são áreas de objetos onde podemos associar um nome (uma string) para identificação de um objeto ao armazená-lo neste contexto. Um analogia bem simples e grosseira seria imaginar um contexto como um Map da API de Collections do Java. Um Map permite associar uma chave (referência ou identificador) a um valor (outro objeto) para localização simples e rápida dos objetos (valor). Contudo, os contextos vão além de um simples MAP e determinam um tempo de vida para os objetos que ali são armazenados. O tempo de vida determina um escopo de existência dos objetos ao torná-los disponíveis para os Servlets e JSP's da aplicação.

Numa aplicação Web simples baseada nas tecnologias Servlet e JSP (ao usar Struts, WebWork e JSF não seria diferente) temos disponíveis os seguintes contextos para armazenar objetos: page, request, session e application.

Escopos Java EE para Web:

• page - Objetos armazenados neste escopo tem o tempo de vida de apenas o tempo de execução (processamento) de uma página JSP no lado do servidor. Após a geração do conteúdo HTML pelo JSP no lado do servidor e o envio deste conteúdo para o browser, as referências para os objetos armazenados neste contexto são perdidos. Podemos imaginar este contexto como o escopo de um método onde declaramos váriaveis locais que são destruídas ao final da execução do método.


• request - Objetos armazenados neste escopo tem o tempo de vida de uma requisição Web realizada por um usuário através do browser. Este escopo passa a existir no momento que o servidor atende a requisição e será destruído ao final da requisição Web quando o conteúdo gerado for enviado para o browser. Este contexto permite armazenar objetos que podem ser passados de um servlet para outro ou de um servlet para uma página JSP se ocorrer um encaminhamento (forward) de um componente para outro enquanto a requisição ainda está em processamento no lado do servidor. Podemos imaginar este contexto como o escopo determinado pela passagem de parâmetros quando um objeto invoca o método de outro objeto.


• session - O contexto de sessão define uma área de objetos no lado do servidor para cada usuário que acessa a aplicação. Este contexto permite armazenar objetos com o mesmo nome para usuários diferentes e existe um isolamento para cada usuário não acessar objetos de outro usuário. Objetos armazenados neste contexto tem um tempo de vida maior que o tempo de vida determinado pelo contexto request e mantem os objetos no lado do servidor enquanto o usuário usar a aplicação Web. Após um período de inatividade do usuário, este contexto será destruído para eliminar somente os objetos deste usuário.


• application - Este contexto define uma área de objetos que tem o tempo de vida da própria aplicação. Quando a aplicação Web entra no ar no servidor de aplicações o contexto application é criado e será destruído somente quando a aplicação for desligada ou o servidor de aplicações sair do ar. Objetos armazenados neste contexto serão compartilhados entre todos os usuários que acessam a aplicação. Este objetos estarão disponíveis para qualquer Servlet e JSP da aplicação Web.

O JBoss Seam define novos contextos para complementar os contextos da Web. Os contextos definidos pelo Seam são tratados como novos contextos e distintos dos contextos do Java EE Web. Contudo, alguns contextos do Seam usam internamente os mesmos contextos do Java EE Web (ou seja, podemos tratar como a mesma coisa!). O Seam disponibiliza os seguintes contextos: stateless, event, page, conversation, session, business process e application.

Escopos do JBoss Seam:

• stateless - Contexto para armazenar a referência para objetos stateless (ex. session stateless EJB). Tecnicamente não é um contexto já que cada busca ou chamada a método num objeto resulta numa nova referência para o bean. Este bean é gerenciado pelo pool de beans do EJB Container.
  

• event - Este contexto é equivalente ao contexto request da Web. Recebe outro nome porque é utilizado em outras situações além de requisições Web como, por exemplo, invocação RMI ou invocação via Seam Remoting aos componentes Seam. Este contexto está associado ao ciclo de vida JSF. Durante o processamento do ciclo de vida os objetos associados estarão disponíveis e serão eliminados somente ao final do ciclo de vida JSF. Inclusive este contexto tem o tempo de vida de uma requisição Ajax realizada pelas bibliotecas de componentes visuais JSF com suporte a Ajax.
  

• page - Este contexto permite armazenar objetos que são criados numa tela JSF e estão disponíveis para esta tela. Este contexto pode ser comparado com o contexto page da Web. Contudo, um objeto armazenado neste contexto estará diponível somente para a tela JSF correspondente que o instanciou a partir de algum listener de evento. Como a documentação sugere, este contexto é útil em alguns componentes visuais como, por exemplo, numa lista clicável de opções que precisa de um objeto com valores específicos para esta lista e tela JSF. Objetos neste contexto estarão disponíveis mesmo em sucessivas requisições Ajax a partir de componentes visuais a partir do browser.
  

• conversation - Aqui está o verdadeiro diferencial do JBoss Seam que agrega valor no desenvolvimento de aplicações Web com JSF. Este contexto permite armazenar objetos que terão um tempo de vida maior que uma requisição (event) e menor que uma sessão (session). Com este contexto se torna possível definir um escopo para objetos que são usados para implementar um fluxo de telas que realizam um "caso de uso" ou "história de usuário". Num Seam Component é possível anotar o início da conversação num método e anotar outro para demarcar o fim da conversação. O curioso deste contexto é que permite abrir várias janelas de browser para uma mesma tela JSF e cada janela representar uma conversação diferente (contexto diferente de objetos) para execução simultânea do mesmo caso de uso. Cada janela é um contexto separado que não influência um outro contexto aberto.
  

• session - Este contexto é equivalente ao contexto Web de mesmo nome. Este contexto define um escopo para manter objetos como, por exemplo, o usuário logado ou outros objetos a serem compatilhados entre várias conversações (escopo de conversação), Além de objetos globais do usuário que acessa a aplicação.
  

• business process - Define um contexto para objetos que são associados a um processo de negócio gerenciado pelo jBPM. Objetos armazenados neste contexto pertencem a um processo e podem ser compatilhados entre vários usuários que acessam o mesmo processo de negócio. Só faz sentido usar este escopo se a máquina de processos implementada pelo jBPM estiver em uso numa aplicação Web em conjunto com o Seam.
  

• application - Este contexto é equivalente ao contexto Web de mesmo nome. Objetos armazenados neste contexto estarão disponíveis para todas as converssações e usuários que acessam a aplicação. Este contexto é útil ao armazenar objetos com conteúdo que não mudam com freqüência para compatilhar para toda aplicação como, por exemplo, configurações ou meta informações. Muitos objetos internos do próprio Seam são armazenados neste contexto.
  

Os contextos indicados acima definem namespaces, já que uma string é usada para dar nome ao objeto armazenado. Como cada contexto é isolado, torna-se possível usar o mesmo nome em contextos diferentes. Os nomes para os objetos armazenados nestes contextos são chamados de context variable. Numa tela JSF, ao usar uma expression language (EL) para associar um componente visual a um objeto (seam component) armazenado num destes contextos, o Seam realiza a busca do objeto a partir do nome indicado na expressão numa ordem de prioridade (event -> page -> conversation -> session -> business process -> application). Por exemplo, ao usar a EL #{usuario.nome} resultará numa busca pelo objeto associado ao nome "usuario" nos contextos na ordem indica e irá parar a busca ao encontrar a primeira ocorrência. Também é possível indicar programaticamente (dentro de um método do Managed Bean ou Seam Component) qual contexto deve obter o objeto sem realizar uma busca nos vários contextos.

Seam Contexts Ilustrado

Preparei a ilustração ao lado para tentar representar os contextos do JBoss Seam. Em estudo recente comecei a compreender melhor estes contextos e a diferença entre Context Variable e Instance Variable. O primeiro tipo de variável representa uma referência para um objeto a partir de um contexto com um nome definido (como os pontos A, B e C na ilustração). O segundo tipo representa um atributo dentro de um Seam Component (como os pontos D e E na ilustração). A partir deste entendimento começou a ficar claro para mim o conceito de Bijeção, ou melhor, a diferença entre injection e outjection. Mas a explicação dessa diferença deixarei para outro post!