Flex: BlazeDS e LazyInitializationException

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

Fala galera.
Ao começar a mexer com BlazeDS + Hiberante, fatalmente o desenvolvedor receberá uma famigerada Lazy. Ao pesquisar na net, vai ver que isso ocorre por causa da serialização que o BlazeDS faz. Já vi algum workaround por aki, como não ter relacionamento nas tabelas (

), alteração do Hibernate e etc.
Então comecei a pesquisar mais sobre o problema e achei esse link interessante. Baseado na idéia dele, efetuei as seguintes alterações em meu código:

1) Extendendo a classe BeanProxy do BlazeDS:

2) Registrar o proxy na inicialização do TOMCAT:

Com isso, em vez de levar a exceção, os valores são setados para null e enviados para o Flex. Estou escrevendo aki para deixar a solução documentada para futuros desenvolvedores e para servir de idéias para novas soluções.

[]s

Virtual Machine Man Membro desde: 22/03/2008 20:07:50 Mensagens: 524 Offline

Ótima iniciativa.. Pretendo contruir um cenário parecido e provavelmente eu teria esse problema... =)... Parabéns

GUJ Master Membro desde: 23/10/2008 06:39:07 Mensagens: 1092 Offline

Eu jah vi esse workaround. Mas sinceramente, Interceptor para engolir excecao pra mim eh a maior gambiarra que tem.

Eu que implementei a solucao da modificacao do Hibernate, acho muito mais facil e mais elegante, qualquer coisa, tem como baixar o codigo fonte e a versao compilada lah no blog...

da um olhada la, eu pelo menos e muita gente achamos esse jeito mais interessante...
[]'s

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

AUser wrote:Eu jah vi esse workaround. Mas sinceramente, Interceptor para engolir excecao pra mim eh a maior gambiarra que tem.

Eu que implementei a solucao da modificacao do Hibernate, acho muito mais facil e mais elegante, qualquer coisa, tem como baixar o codigo fonte e a versao compilada lah no blog...

da um olhada la, eu pelo menos e muita gente achamos esse jeito mais interessante...
[]'s

Eu já tinha dado uma olhada na sua solução, mas sinceramente, mexer no src do Hibernate eu não fico confortável. Uma vez que o problema estava na serialização, achei bem melhor capturar a Exceção e setar nulo para o campo, podendo assim atualizar minha versão do Hibernate sem ter dor de cabeça. De qq forma, ficam as duas opções pro pessoal testar e usar a que preferir

. No link que mandei, achei bem interessante também um post do mesmo autor falando sobre segurança durante o uso do Flex/Air.

[]s

GUJ Master Membro desde: 23/10/2008 06:39:07 Mensagens: 1092 Offline

renzonuccitelli wrote:

AUser wrote:Eu jah vi esse workaround. Mas sinceramente, Interceptor para engolir excecao pra mim eh a maior gambiarra que tem.

Eu que implementei a solucao da modificacao do Hibernate, acho muito mais facil e mais elegante, qualquer coisa, tem como baixar o codigo fonte e a versao compilada lah no blog...

da um olhada la, eu pelo menos e muita gente achamos esse jeito mais interessante...
[]'s

Eu já tinha dado uma olhada na sua solução, mas sinceramente, mexer no src do Hibernate eu não fico confortável. Uma vez que o problema estava na serialização, achei bem melhor capturar a Exceção e setar nulo para o campo, podendo assim atualizar minha versão do Hibernate sem ter dor de cabeça. De qq forma, ficam as duas opções pro pessoal testar e usar a que preferir . No link que mandei, achei bem interessante também um post do mesmo autor falando sobre segurança durante o uso do Flex/Air.

[]s

Bem, lá no blog tem assim como o source, o JAR já modificado lá, da última versão. Ficou bem grande a explicacao pq quis mostrar a todos o que acontece, com detalhes de classe, etc.

Mas enfim, verdade, opções não faltam, em pensar que há pouco tempo atrás tinha apenas uma...

[]'s!

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

AUser wrote:

renzonuccitelli wrote:

AUser wrote:Eu jah vi esse workaround. Mas sinceramente, Interceptor para engolir excecao pra mim eh a maior gambiarra que tem.

Eu que implementei a solucao da modificacao do Hibernate, acho muito mais facil e mais elegante, qualquer coisa, tem como baixar o codigo fonte e a versao compilada lah no blog...

da um olhada la, eu pelo menos e muita gente achamos esse jeito mais interessante...
[]'s

Eu já tinha dado uma olhada na sua solução, mas sinceramente, mexer no src do Hibernate eu não fico confortável. Uma vez que o problema estava na serialização, achei bem melhor capturar a Exceção e setar nulo para o campo, podendo assim atualizar minha versão do Hibernate sem ter dor de cabeça. De qq forma, ficam as duas opções pro pessoal testar e usar a que preferir . No link que mandei, achei bem interessante também um post do mesmo autor falando sobre segurança durante o uso do Flex/Air.

[]s

Bem, lá no blog tem assim como o source, o JAR já modificado lá, da última versão. Ficou bem grande a explicacao pq quis mostrar a todos o que acontece, com detalhes de classe, etc.

Mas enfim, verdade, opções não faltam, em pensar que há pouco tempo atrás tinha apenas uma...

[]'s!

Pois é, eu li os seus artigos e indiquei para amigos, achei bem interessantes. Mas como eu disse, eu prefiro não mexer no código do Hibernate. Como agora, haverá uma atualização dessa biblioteca. Eu teria que ir no código e refazer sua alteração, e torcer pra não acontecer nenhum efeito colateral. Mas assim com vc, acho bom ter várias soluções e cada desenvolver ver quais as vantagens e desvantagens de cada uma.

[]s

Entusiasta Java Membro desde: 24/03/2010 13:59:13 Mensagens: 21 Offline

Bem, outra solução seria a implementação de um filter, semelhante ao padrão "Open Session In View". Aliás, foi assim que consegui resolver o problema de forma efetiva nos projetos que desenvolvi utilizando estas tecnologias. Siga o mesmo conceito de conversação do Seam, por exemplo, e você já terá a base de como implementar o filter, que não deve fazer nada de mais além de gerenciar a abertura/fechamento das sessões/transações, liberando os objetos que estiverem à elas amarradas, pois por mais que você não encerre a sessão até garantir que todos os objetos tenham sido retornados, você vai ver outro erro, informando-o de que não é possível modificar objetos que estão atrelados à sessão corrente.

Exemplo:

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

diego.hordi wrote:Bem, outra solução seria a implementação de um filter, semelhante ao padrão "Open Session In View". Aliás, foi assim que consegui resolver o problema de forma efetiva nos projetos que desenvolvi utilizando estas tecnologias. Siga o mesmo conceito de conversação do Seam, por exemplo, e você já terá a base de como implementar o filter, que não deve fazer nada de mais além de gerenciar a abertura/fechamento das sessões/transações, liberando os objetos que estiverem à elas amarradas, pois por mais que você não encerre a sessão até garantir que todos os objetos tenham sido retornados, você vai ver outro erro, informando-o de que não é possível modificar objetos que estão atrelados à sessão corrente.

Exemplo:

public void doFilter( ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain ) throws IOException, ServletException { try{ HibernateSessionFactory.getInstance().openSession(); HibernateSessionFactory.getInstance().beginTransaction(); filterChain.doFilter( servletRequest, servletResponse ); HibernateSessionFactory.getInstance().commit(); HibernateSessionFactory.getInstance().close(); } catch( Exception e ){ e.printStackTrace(); } }

Na realidade essa solução não resolve, na minha opinião. Isso porque o serializador Blaze vai chamar todos os método get, e não só os que a View precisa, diferentemente do que ocorre com uma JSP. Assim, na prática vc estara carregando todos os dados da mesma forma que se setasse o fetch type para EAGER, uma vez que a sessão estará aberta e as coleções serão todas inicializadas.

Em tempo, um amigo deu uma melhorado no primeiro código que fiz, mas serve só para o Hibernate. Em vez de capturar a Exception, ele usa o Hibernate.isInitialized() (acho que é esse o nome) para verificar se o campo está inicializado. Mesmo assim dá pra usar para outros implementadores do JPA se eles fornecerem algum método parecido.

Entusiasta Java Membro desde: 24/03/2010 13:59:13 Mensagens: 21 Offline

Sim, é a aplicação do conceito de instancialização "Eager", que prima pela performance ao invés da preservação de memória. Todavia, este tipo de controle permite a construção do objeto e somente de suas dependências, e não de toda a coleção à qual faz referência.

Nos projetos de ERP que arquitetei que utilizavam estas tecnologias, após vários testes, vimos que esta estratégia era a melhor à ser adotada. Posso explicar isso através de um exemplo. Pense no gerenciamento dos lançamentos contábeis de uma empresa. Dificilmente, mas muito dificilmente mesmo, o usuário vai requisitar somente a descrição, a data e o valor do lançamento, sem também querer ver à quais contas ele foi creditado/debitado. Ao invés de fazer requisições para poupar o uso (temporário) de memória do servidor, não seria melhor eu transferir este objeto (Lançamento Contábil) completo, com todas e somente as suas dependências (Contas crédito, contas débito, histórico padrão...) para o front, fazendo uma espécie de load balance?

É claro, esta decisão vai depender muito da arquitetura/requisitos do seu software.

[]'s
Diego

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

diego.hordi wrote:Sim, é a aplicação do conceito de instancialização "Eager", que prima pela performance ao invés da preservação de memória. Todavia, este tipo de controle permite a construção do objeto e somente de suas dependências, e não de toda a coleção à qual faz referência.

Nos projetos de ERP que arquitetei que utilizavam estas tecnologias, após vários testes, vimos que esta estratégia era a melhor à ser adotada. Posso explicar isso através de um exemplo. Pense no gerenciamento dos lançamentos contábeis de uma empresa. Dificilmente, mas muito dificilmente mesmo, o usuário vai requisitar somente a descrição, a data e o valor do lançamento, sem também querer ver à quais contas ele foi creditado/debitado. Ao invés de fazer requisições para poupar o uso (temporário) de memória do servidor, não seria melhor eu transferir este objeto (Lançamento Contábil) completo, com todas e somente as suas dependências (Contas crédito, contas débito, histórico padrão...) para o front, fazendo uma espécie de load balance?

É claro, esta decisão vai depender muito da arquitetura/requisitos do seu software.

[]'s
Diego

No caso de vc sempre querer enviar os dados, basta colocar como EAGER

. O problema que estou me referindo é outro. Dessa maneira, propriedade marcadas como LAZY serão inicializadas também. Um exemplo comum, uma classe pessoa tem várias referencias, como endereços, controles de pagamentos, controle de pessoal. Muito provavelmente a pessoa não vai querer ver seus endereços e controles de pagamentos ao mesmo tempo. Aí, se toda hora vc ficar enviando esses dados inuteis, vai ter problema de performance com certeza, trazendo um grafo completos de objetos e não utilizando muitos deles. Aki na empresa estamos passando por isso. Se o serializador conseguisse "pedir só o que necessita", assim como um JSP, dava pra usar numa boa, mas como não é o caso, fica inviável.

Mas é sempre bom ter diversas opiniões, assim cada um pode colocar em prática todas elas e usar a que mais lhe parecer adequada.

[]s

Entusiasta Java Membro desde: 24/03/2010 13:59:13 Mensagens: 21 Offline

É. É verdade, opiniões nunca são demais.

Mas o que posso te adiantar é: faça vários testes, vários mesmo. Ficamos aproximadamente umas 4 semanas testando e buscando soluções para contornar este problema e viabilizar uma solução que fosse de encontro à nossa necessidade. Você vai ver que "Lazy" é só um dos problemas ao se trabalhar com sistemas grandes utilizando o Flex, que por sinal é uma ferramenta excepcional.

[]'s
Diego.

What is classpath? Membro desde: 03/06/2009 12:48:11 Mensagens: 9 Offline

viniciusfaleiro wrote:2) Registrar o proxy na inicialização do TOMCAT:

PropertyProxyRegistry.getRegistry().register(Object.class, new MyBeanProxy());

Com isso, em vez de levar a exceção, os valores são setados para null e enviados para o Flex. Estou escrevendo aki para deixar a solução documentada para futuros desenvolvedores e para servir de idéias para novas soluções.

Como registrar o proxy na inicilizacao do TOMCAT?

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

wpsouto wrote:

viniciusfaleiro wrote:2) Registrar o proxy na inicialização do TOMCAT:

PropertyProxyRegistry.getRegistry().register(Object.class, new MyBeanProxy());

Com isso, em vez de levar a exceção, os valores são setados para null e enviados para o Flex. Estou escrevendo aki para deixar a solução documentada para futuros desenvolvedores e para servir de idéias para novas soluções.

Como registrar o proxy na inicilizacao do TOMCAT?

Use um Listener.
Atualmente fiz um framework com uma arquitetura bem bacana de chamadas remotas em FLEX usando o Google App Engine, o JFera. O problema é que ainda estou documentando. Mas nesse projeto eu usei o GraniteDS e gostei muito. A documentação é bem melhor que a do Blaze, integra facilmente com Spring e, o melhor de tudo, resolve o problema de Lazy para o Hibernate. Para quem não tiver como requisito usar o Blaze, recomendo dar uma ulhada no graniteds.org.

[]s

This message was edited 1 time. Last update was at 05/08/2010 11:32:21

Use um Listener.Atualmente fiz um framework com uma arquitetura bem bacana de chamadas remotas em FLEX usando o Google App Engine, o JFera. O problema é que ainda estou documentando. Mas nesse projeto eu usei o GraniteDS e gostei muito. A documentação é bem melhor que a do Blaze, integra facilmente com Spring e, o melhor de tudo, resolve o problema de Lazy para o Hibernate. Para quem não tiver como requisito usar o Blaze, recomendo dar uma ulhada no graniteds.org.

Da uma olhada neste screencast bem bacana e fala sobre Adobe Flex 4, Java e Google App Engine - Alta escalabilidade para sua aplicação nas nuvens.

https://admin.na3.acrobat.com/_a204547676/p79647321/

GUJ Master Membro desde: 17/09/2008 12:58:32 Mensagens: 1133 Offline

wpsouto wrote:

Use um Listener.Atualmente fiz um framework com uma arquitetura bem bacana de chamadas remotas em FLEX usando o Google App Engine, o JFera. O problema é que ainda estou documentando. Mas nesse projeto eu usei o GraniteDS e gostei muito. A documentação é bem melhor que a do Blaze, integra facilmente com Spring e, o melhor de tudo, resolve o problema de Lazy para o Hibernate. Para quem não tiver como requisito usar o Blaze, recomendo dar uma ulhada no graniteds.org.

Da uma olhada neste screencast bem bacana e fala sobre Adobe Flex 4, Java e Google App Engine - Alta escalabilidade para sua aplicação nas nuvens.

https://admin.na3.acrobat.com/_a204547676/p79647321/

O problema era a arquitetura antiga do Cairgorm 2 e mesmo o 3 eu não gostei. Montei uma arquitetura que vc apenas lança eventos comuns no Flex e eles executam no servidor. Quando eu terminar a documentação, posto aki.

[]s

Notícias, artigos e o maior fórum brasileiro sobre Java