Na verdade seu caso � um caso tipico do pattern Value List Handler. D� uma olhada na site da sun.
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. Detalhe, utilizando EJB com XA datasources, vc pode manter uma transa��o com varias bancos diferente. Alessandra Requena wrote: > Mas eu estou utilizando EJB porque estou realizando um trabalho na >universidade de compara��o de tecnologias, principalmente an�lise >performance. Estes acessos �s diversas bases devem estar em m�quinas >distintas(claro que isso n�o significa que devem ser EJBs). >Mas porque isso n�o seria caso t�pico de utiliza��o de EJB? O ambiente � >altamente distribu�do, sendo que o acesso � cada uma das n bases de dados >devem acontecer em m�quinas diferentes, al�m de eu ter que fazer um merge >destes resultados em um ponto comum. � muito boa uma pergunta como a sua, eu >tamb�m acho que � question�vel a utiliza��o de EJB neste caso e quanto mais >sugest�es melhor(tamb�m para me preparar para a banca...). A sua id�ia de >threads(se eu entendi) s� funcionaria para o meu caso se eu utilizasse RMI >para a intera��o entre a minha aplica��o e a que se encontra no site da base >de dados, certo? Voc� acha que isto � uma solu��o melhor do que utilizar >message-driven beans? > >-----Mensagem original----- >De: Alexandre G. L. Fernandes [mailto:[EMAIL PROTECTED]] >Enviada em: quarta-feira, 27 de mar�o de 2002 11:30 >Para: [EMAIL PROTECTED] >Assunto: Re: [enterprise-list] Consulta paralela a n bases de dados > >Oi, Alessandra, >Pelo que entendi vc pretende implementar a camada de persist�ncia atrav�s de >EJB's... Mas por que precisam ser EJB's? N�o parece ser o caso t�pico de >utiliza��o dos mesmos... se fossem classes normais, vc poderia usar threads >e com isso implementar o sincronismo necess�rio sem muitos problemas... o >�nico problema poderia ser o pool de conex�es com cada uma das bases, mas se >n�o me engano o novo jdbc j� implementa este pool. >[]'s >Alexandre. > >--------------------------------------------------------------------- >Para cancelar a subscri��o, envie mensagem para: >[EMAIL PROTECTED] >Para comandos adicionais, envie mensagem para: >[EMAIL PROTECTED] > >--------------------------------------------------------------------- >Para cancelar a subscri��o, envie mensagem para: >[EMAIL PROTECTED] >Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] > --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
