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]

Responder a