Sven van �t Veer wrote: > > Na verdade seu caso � um caso tipico do pattern Value List Handler. D� > uma olhada na site da sun. Oi, Sven, eu n�o conhe�o este pattern, e tamb�m n�o o encontrei no site da sun... Tem certeza de que � este nome mesmo?
> > No seu caso utiliza��o de EJB � a op��o certa, somente acho que n�o > deveriam ser EntityBeans, a n�io ser que cada find devolve somente > poucas entities. Os ejb�s nem precisam ser distribuido, podem ficar em > uma maquina so, basta vc criar um outro connection pool. Pelo que tinha entendido do problema proposto, trata-se de consultas read-only, como de fato a Alessandra confirmou num email mais recente. Isso pra mim descarta a possibilidade de EntityBean, e tamb�m elimina a necessidade de usar bibliotecas XA. Se vc n�o vai escrever nada, n�o precisa controlar a transa��o distribu�da. Ah, e finalmente, se n�o for pra distribuir, a� � que n�o precisa de EJB mesmo!!!! Mas Alessandra, agora que vc disse que trata-se de um projeto pra faculdade faz mais sentido sua necessidade de usar ejb. O que vc quer saber � como fazer um EJB disparar v�rios processos de consulta paralelos e ficar esperando todos os resultados voltarem pra process�-los e mandar uma resposta para quem o chamou. Se n�o me engano, foi exatamente o que vc escreveu no primeiro email, mas o processo de entendimento do problema nem sempre � linear... :) Resposta: n�o sei. N�o sei fazer isso sem usar threads, e como ejb n�o pode disparar threads, ent�o eu o "tirei fora da jogada". Talvez com message driven beans seja poss�vel criar um esquema do tipo bulletin board, em que vc pendura requisi��es em uma lista e um processo (que n�o � um ejb! :) ) fica respons�vel por chamar os objetos respons�veis por solucionar cada um deles (acho que tem um pattern pra isso). Mas n�o sei como eu faria pra deixar o ejb "esperando", nem como fazer o call back (message driven beans resolve isso?). Talvez usar beans stateless e vc mesma controlar um contexto, ao qual diferentes inst�ncias do bean teriam acesso... Hoje, pra um projeto real que tivesse uma arquitetura semelhante � que vc est� propondo, talvez eu optasse por usar classes normais como providers de cada banco, disparadas em diferentes threads por um proxy que tamb�m seria uma classe n�o ejb, RMI pra distribuir estes providers e o pool do jdbc. N�o seria uma maravilha da implementa��o, mas com certeza funcionaria a contento! :) Por �ltimo, quanto � usar o esquema proposto pelo �lvaro, Session beans acessando persist�ncia implementada com DAO's, (que considero a melhor arquitetura para sistemas mais robustos) isso eliminaria a possibilidade de usar threads. Da� vc teria que implementar com message driven beans mesmo. � isso a�! Lamento n�o poder ajudar mais. []'s Alexandre (com participa��o especial do Marcelo Vessoni) --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
