Web Beans chegando...

Primeiro preview liberado!
Veja.

Salvando entidades além do convencional

Outro dia encontrei algumas referencias comentando/procurando uma solução simples a respeito da persistência de entidades que possuem relacionamentos com certa complexidade (além do CRUD básico) com JPA/Hibernate, algo normal ao usar "domain model".

Pra não voltar aos DTO's, uma abordagem - questionável é claro - seria usar o id do objeto de origem para resgatar uma outra instância sob o escopo do EntityManager/Session e setar os "pedaços"/dados modificados no objeto origem na referencia gerenciada.

...
//recuperando instância gerenciada
Pedido pedidoGerenciado = getPedidoById(pedidoOrigem.getId());

//passando informações desejadas...
pedidoGerenciado.setDataEntrega(pedidoOrigem.getDataEntrega());
...

Ao encerrar a transação ou acionar o flush as alterações serão propagadas ao Banco.

Sunday Reference

Domingão resolvi dar uma revisada na API do Java que trata referencias de objetos (Heap + GC). Semana passada me deparei com algumas delas nos testes que estava fazendo (post anterior).

Na realidade brinquei um pouco as especializações de java.lang.ref.Reference. Representam o modelo de referencia de objetos do Java e influenciando a execução do Garbage Collector (GC). São elas:

• WeakReference: um wrapper de uma referencia (qualquer objeto) "fraca", quando necessario o GC ira eliminar.

• SoftReference: outro wrapper, mas numa situação intermediaria nem tao fraca e nem tao forte. Na pratica tem uma durabilidade maior do que weak, mas qdo necessario - se necessário - o GC vai eliminar. Uma alternativa interessante para cache.

• PhantomReference: o wrapper mais "frágil", o objeto já recebeu sua doze letal sem chance de escapar da pena de morte. Não há recuperação, o método get sempre retorna null.

Além dessas 3, temos outras classes nessa API:

• ReferenceQueue: mantém as referencias elegíveis enfileiradas.

• WeakHashMap: Map composto pela chave WeakReference e valor a referencia, que sabe eliminar a chave qdo o valor for coletada pelo GC. Em outras coleções o WeakReference (ou os outros) não são removidos, apenas a referencia encapsulada.

Acesse o javadoc e confira.

JVM - "Caixa Preta"

Gerenciar e monitorar os componentes e recursos utilizados por uma aplicação é uma tarefa complexa. Descobrir a causa de OutOfMemory não é algo simples, vc pode encontrar varios sites comentando sobre o problema e tentando apresentar uma solucao. O óbvio seria fazer uma analise da sua aplicação, mas como fazer um "top" para o Java?

Pra isso temos o "profile", ferramente que monitora "de cabo a rabo" o que o aplicativo esta fazendo e consumindo. Na teoria a ferramenta é perfeita, mas na pratica o uso pode ser inviável. Alguns colegas até brincam dizendo que "profile é perfeito, desde que vc não use em produção"! Por mais que vc tenha replicas do ambiente de produção, uma ótima cobertura de testes de stress/utilização, infelizmente alguns comportamentos só ocorrem no ambiente real! E agora?

Junto com a evolução da linguagem Java, a JVM também vem evoluindo bastante no quesito rastreabilidade e monitoramento, no Java 6 foram incorporadas algumas ferramentas com essas características. Na semana passada gastei um tempo estudando e testando algumas dessas ferramentas:
- jmap: faz um dump dos objetos da memória em arquivo físico: > jmap -dump:file=heap.bin
- jhat: ferramenta usada para fazer analise do dump: > jhat -J-mx512m heap.bin
- VisualVM: ferramenta gráfica para acompanhar/monitorar sua aplicação durante a execução. Mais funcionalidades do que o JConsole.

A partir da versão 6, é possível usar um parâmetro solicitando um "dump automático" da memória no caso de um OutOfMemory. Adicione o parâmetro -XX:HeapDumpPath=path_to_file no comando java (avalie o custo).

Tomara que com a evolução da plataforma no geral, essas ferramentas continuem melhorando, simplificando a vida de quem desenvolve e cuida do ambiente Java.

Mas, em casos mais complexos talvez vc tenha que apelar para o Profile, pagando o preço. Atualmente estou trabalhando com o Introscope da CA, uma ferramenta bem completa com consumo razoável, funciona sem "derrubar" o servidor.

Tive algumas experiencias com JProfile e YourKit.

JSessionId em múltiplos contextos

Quando 2 aplicações dentro de um mesmo host/domínio usam sessão, se permitido, um cookie que armazena o jsessionid será gerado na maquina do cliente. Apenas um cookie ja que a criação é por dominio e não por contexto. Aparentemente nenhum problema, mas isso pode gerar um comportamento estranho e difícil de identicar.

No server-side (container) para as 2 aplicações teremos 2 instâncias de HttpSession um por contexto, da forma que deve ser. O jboss sabe mapear a request com o HttpSession do contexto correto, sem problemas.

Mas e se ...? O problema:

• A aplicação X, com o erro intermitente, tem um time-out de session de 5 minutos.
• X possui uma tela faz busca em outro contexto, a aplicação Y.
• O host de Y eh o mesmo de X, e o seu time-out é de 2 minutos por exemplo.
• O usuario ao autenticar em X e abrir a tela que aciona Y, sem saber possui 2 sessions, uma para cada aplicação, mas somente um cookie!
• Caso o usuário depois ficasse 2 minutos trocando uma idéia no msn ou tomando um cafézinho, ao voltar pra tela que aciona Y, uma nova session seria gerada, já que a anterior expirou. Nova session, novo jsessionid, novo cookie!
• Ao fazer uma request para X, o container ira receber um jsessionid desconhecido para o contexto, e ai adivinha? Session "perdida".

Ficamos quase uma semana de cabelo em pé, para descobrir o porque do "sumiço" da session Demorou pra se ligar nesse detalhe.