[enterprise-list] =?iso-8859-1?Q?Acesso_=E0_beans_sob_demanda=2E_Problema_de_per?==?iso-8859-1?Q?formance_no_Jboss?=

[Paulo Andre Antonialli]

Bom dia amigos. Desenvolvemos uma aplica��o para rodar no cliente (utilizando EJB e J2EE). O cliente, inicialmente, havia dito que seus computadores teriam 256 de ram. Pois bem, desenvolvemos uma aplica��o piloto (com funcionalidades reduzidas) e, para nossa surpresa, o pc do cliente possu�a apenas 64 de ram, ou seja, a performance de nossa aplica��o n�o foi t�o aceit�vel assim. O grande problema foi o seguinte: Instalamos tudo e, na hora que fomos dar a carga nos beans, o Jboss levou MUITO tempo (mais especificamente, quase 5 mins) para levantar. Acredito que ele demorou muito porque estava fazendo o cache dos beans. Disse "acredito" porque n�o fui eu quem instalou a aplica��o. Pois bem, algu�m saberia me apontar na dire��o de melhorar a performance de "levantamento" deste container? Pensei num modelo sob-demanda, ou seja, o Jboss carregaria somente os beans que fossem pedido � ele. Vejo que isso poderia diminuir o n�mero de beans que seriam carregados pelo container na hora em que ele estiver sendo levantado e, conseq�entemente, melhoraria a performance em tempo de deployment. Por outro lado, acho que a performance do aplicativo em tempo de execu��o cairia porque os beans n�o estariam "cacheados" . Esse meu pensamento � correto? Caso seja, como resolver esse paradoxo? O Jboss possui uma funcionalidade "read-ahead". O que seria exatamente esta funcionalidade? J� estou utilizando alguns patterns (session fa�ade, service locator, Business delegate e value objects) e tamb�m struts. Li uma vez na lista que, quando devemos carregar uma combo com uma quantidade grande de valores, que o Data Access Object Pattern (DAO) seria mais indicado do que fazer a carga da combo na entitiy. Minha aplica��o n�o foi desenvolvida seguindo este pattern... o refactoring da minha aplica��o para a �"adapta��o" do DAO seria muito custosa? (dif�cil?demorada?)   Muito obrigado e um grande abra�o � todos desta lista, o n�vel das discuss�es aqui presentes realmente � excelente!