Alessandra D� um olhada no Castor. http://castor.exolab.org. (Implementa DAO - bem mais leves que os Entities) Vc pode definir seus Sessions acessando a camada de Persist�ncia implementada com Castor.
�lvaro Alessandra Requena wrote: >Sven, > > Eu vou dar uma olhadinha neste pattern. Na verdade, eu n�o uso >Entity bean. Eu estou utilizando session com DAO, pois a quantidade de dados >que eu retorno � grande e � somente read-only. Eu sei que n�o precisa estar >em m�quinas separadas, mas a log�stica da aplica��o, se � que se pode dizer >que aplica��o tem log�stica, enfim, me obriga a ter isso, pois a manuten��o >destes componentes � independente e a string de conex�o � base de dados eu >n�o sei. Al�m disso, executando em uma m�quina eu somente teria uma >impress�o de execu��o das consultas paralelas, pois elas n�o estariam >realmente acontecendo paralelamente, n�o �? > >Obrigada pela aten��o! > > >-----Mensagem original----- >De: Sven van �t Veer [mailto:[EMAIL PROTECTED]] >Enviada em: quarta-feira, 27 de mar�o de 2002 12:08 >Para: [EMAIL PROTECTED] >Assunto: Re: RES: [enterprise-list] Consulta paralela a n bases de dados > >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] > >--------------------------------------------------------------------- >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]
