Replicação de sessão com VRaptor 3.5 e Cluster de Tomcat 7

Olá pessoal, hoje vou mostrar detalhes de uma aplicação desenvolvida com VRaptor rodando em um cluster de Tomcat 7.

Características da Aplicação

A aplicação foi desenvolvida utilizando:

• JDK 6;
• VRaptor 3.5.3;
• Spring 3.0.5, como provider de IoC/DI;
• Banco de dados PostgreSQL.

Características do Ambiente

O ambiente foi projetado com: 

• Apache Web Server 2.2.22;
• Sendo responsável pelo balanceamento de carga;
• Tomcat 7.0.54;
• JVM versão 6;
• Sendo este um cluster de 2 nós.

Regras para replicação de sessão em Java EE

Para que possamos trabalhar com cluster em um ambiente Java EE, a aplicação deve seguir algumas regras, que são as seguintes:

• A aplicação deve ter a tag <distributable /> no deployment descriptor;
• Todos os dados que serão replicados, devem implementar a interface java.io.Serializable;
• Para armazenar ou alterar um objeto na sessão, sempre devemos invocar o método setAttribute. 

Seguindo estas regras, podemos afirmar que aplicação pode funcionar em um ambiente de cluster.

O VRaptor

O VRaptor é um framework utilizado para o desenvolvimento de aplicações web, os principais recursos que o tornam uma ótima escolha para a camada Web Tier são as seguintes:

• Baseado em REST;
• Fácil integração com outros frameworks como Spring, Tiles, Velocity, etc;
• Suporte e documentação;
• Fácil geração e manipulação de XML e JSON;
• Possibilidade de troca do provider de IoC/DI.

Observação: Neste tutorial estamos usando a versão 3.5.3 do VRaptor, que utiliza o Google Guice como provider padrão para IoC, atualmente o VRaptor encontra-se na versão 4.0.0, onde seu core foi reescrito e padronizado para utilizar CDI (Context Dependecy Injection), para mais detalhes acesse o site oficial do framework. 

Tratamento de objetos com @SessionScoped

Em quase todas aplicações web trabalhamos com dados na sessão, seja ele para autenticar um usuário, ou para manter estado em chamadas ao servidor, com VRaptor, podemos marcar uma classe para que tenha seu estado armazenado na sessão, isso acontece com a anotação @SessionScoped.

O Problema

Um dos grandes problemas quando trabalhamos em ambientes clusterizados é a replicação de sessão, quando uma sessão tem seus dados alterados, o contêiner deve replicar esta alteração entre os nós do cluster, assim garantindo a confiabilidade do sistema.

Em nosso exemplo, utilizei o Spring como provider de IoC/DI, assim ele será o responsável por gerenciar a criação e manipulação dos objetos do VRaptor.

Ao realizar o deployment da aplicação tudo acontece normalmente, mas notamos, que ao alterar um objeto marcado como @SessionScoped a alteração mesmo não é replicada entre os nós do cluster.

A Solução 

Para encontrar um solução para o problema, foram executado uma bateria de testes no sistema, para que o motivo dessa falha fosse descoberto, segue os testes:

• Realizar alteração na sessão invocando diretamente o método setAttribute da classe HttpSession;
• Manipulação dos listeners HttpSessionAttributeListener, HttpSessionBindingListener e HttpSessionActivationListener pertencentes ao pacote javax.servelet.http.*, com eles seria possível monitorar as alterações nos atributos da sessão e também a migração entre JVMs;
• Trocar o Spring pelo Google Guice, como do provider de IoC/DI do VRaptor.

Ao realizar o ultimo teste, tivemos um resultado positivo, pois os objetos marcados como @SessionScoped foram replicados entre os nós do cluster, garantindo assim a confiabilidade do sistema.

Para utilizar o Google Guice como provider é muito simples, porque como mencionei acima, ele é o provider padrão utilizado pelo VRaptor 3.5.

Referências sobre as tecnologias utilizadas:

• Google Guice;
• VRaptor 3 e VRaptor 4;
• Documentação Tomcat 7;
• Documentação Apache Web Server;
• Java EE Listeners.

Até a próxima.