Se da erro, então pra que serve o LAZY?
Danilo Magrini
persist, merge etc. Daí tenho uma classe X EJB Stateless que recebe a
injeção de um Entity Manager e repassa para o DAO fazer o serviço.
Essa classe X é injetada em um Managed Bean que faz o seguinte: Faz
uma busca por um CPF na classe Pessoa que possue um relacionamento 1xN
Lazy com uma classe Emails. No meu JSP eu tenho um dataTable que
renderiza os emails de Pessoa, porém quando o CPF já existe e o find
retorna a classe Pessoa populada recebo o seguinte erro:
"Received 'org.hibernate.LazyInitializationException' when invoking
action listener '#{controleBean.buscarPorCpfCnpj}' for component
'j_id606'
org.hibernate.LazyInitializationException: failed to lazily initialize
a collection of role: br.com.saybien.modelos.pessoas.Pessoa.emails, no
session or session was closed"
Estou usando JPA e controle de transação gerenciada pelo container
(JTA), portanto não sou eu quem abre ou fecha sessão. Pesquisando no
Livro "Enterprise JavaBeans 3.0" da editora O'Reilly, obtive a
seguinte informação: "O problema dessa inicialização sob demanda pode
ser resolvido de duas maneiras. A maneira óbvia é simplismente navegar
pelos objetos relacionados necessários enquanto a instância de
entidade continuar gerenciada por um contexto de persistência. A
segunda maneira é realizar a carga imediata quando você consulta a
entidade." Peraí, se eu tenho que carregar os relacionamentos sempre
dentro da mesma sessão JPA não faz o mínimo sentido eu ter
relacionamentos sob-demanada (LAZY) concordam?
Alguém já passou por isso? Melhor eu botar EAGER em tudo mesmo ou
estou modelando de forma errada meu projeto?
grato.
--
Danilo G. Magrini
danilo.magrini (AT) gmail (DOT) com
GPG Key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x3EAD0BBAFDE75A11
"Any fool can write code that a computer can understand. Good
programmers write code that humans can understand." (Martin Fowler)
George Queiroz
[s]G-BA
Gilliard Cordeiro
Procure na internet sobre o problema N+1 queries para ter uma idéia do problema.
Uma resposta bem simples é você carregar esse relacionamento somente quando você precisa. Se vai fazer uma listagem dos emails entao carregue os emails (tem mais de uma forma de fazer isso, dê uma pesquisada em join fetch).
Mas se simplesmente colocar EAGER quando precisar fazer uma listagem simples de usuários em um combo você trará do banco também todos os emails de cada um, ou seja, vai lascar sua aplicação.
Outra coisa é o lazy acontece porque o objeto está detached. Se quando for fazer alguma operação com ele você reanexá-lo a um EntityManager, não vai ter problema de lazy.
E se você tiver opção, recomendo pensar no Seam, que é feito justamente com o objetivo de integrar jsf e ejb3.
--
Gilliard Cordeiro
http://gilliard.eti.br
danilo silva
Gilliard Cordeiro
Danilo Magrini
> sua tela ta tendando ler uma coleção que o hibernate só colocou o proxy
> dele, daí dá esse erro, se vc tem necessidade do Pessoa.emails, carrege-o
> antes de retornar, senão, se for por demanda, faça um método que pegue os
> emails da pessoa na hora devida.
pois é, não sou eu quem devo pegar na hora devida e sim o JSF já que
ele faz esse acesso em algum momento do seu Lifecycle.
Danilo Magrini
> EAGER vai lascar sua aplicação.
Sim concordo, por isso estou batendo em cima do LAZY.
> Outra coisa é o lazy acontece porque o objeto está detached. Se quando for
> fazer alguma operação com ele você reanexá-lo a um EntityManager, não vai
> ter problema de lazy.
Infelizmente não sou eu que estou tentando obter programaticamente o
objeto emails do Pessoa e sim o JSF.
> E se você tiver opção, recomendo pensar no Seam, que é feito justamente com
> o objetivo de integrar jsf e ejb3.
Não tenho opção. Tem que ser sem o SEAM mesmo.
Gilliard Cordeiro
db
Ao invés de implementar um Filter, você poderia implementar um PhaseListener...
Eu nunca tentei... Se você conseguir sem o Seam, por favor, poste aí...
Abraços
db
Danilo Magrini
cara vou dar uma olhada... obrigado pela dica. Se for viável e eu
conseguir implementar eu coloco aqui.
Danilo Magrini
> 2009/9/9 db <dbco...@gmail.com>:
>> Danilo, andei pesquisando sobre isso e achei isso aqui:
>> https://www.hibernate.org/43.html
acabei de olhar e pra mim não server pois eu uso JPA e JTA.
Glauco P. Gomes
Glauco P. Gomes
Danilo Magrini escreveu:
Glauco P. Gomes
Glauco P. Gomes
danilo silva escreveu:
Danilo Magrini
> Porque nao? Uma sessao é diferente de uma transacao, em uma unica sessao
> pode se ter varias transacoes.
Usando JPA/EJB3, quando que um contexto de persistência (session) abre
e quando ele fecha? Já que eu não faço isso manualmente...
Glauco P. Gomes
https://www.hibernate.org/42.html
De forma totalmente automatica nao tem como resolver. Vc que vai ter que abrir e fechar a sessao.
Glauco P. Gomes
Danilo Magrini escreveu:
2009/9/9 Glauco P. Gomes <glauco...@yahoo.com.br>:
Danilo Magrini
> abrir e fechar a sessao.
Se for assim então não faz sentido o container injetar EnityManager e
gerenciar as transações... Melhor que eu faça tudo na unha mesmo. Pra
quem vem do mundo desktop, esse HTTP é um retrocesso tecnológico afe.
Ubirailson Jersy
--
Cordialmente,
Ubirailson Jersy
Glauco P. Gomes
Verifica se neste seu caso, a inicializacao por LAZY realmente é vantajosa.
Glauco P. Gomes
Glauco P. Gomes
Vc pode utilizar Spring?
Glauco P. Gomes
Danilo Magrini escreveu:
2009/9/9 Glauco P. Gomes <glauco...@yahoo.com.br>:
Rafael Ponte
Dica: Procure um framework que gerencie seus componentes de software (seja managed bean ou não). Como Spring ou mesmo JBoss Seam, pois JSF "puro" é praticamente um atraso de vida.
Abraços.
Outra coisa, vc realmente precisa de EJBs? Sua aplicacao é distribuida?
Vc pode utilizar Spring?
Glauco P. Gomes
Danilo Magrini escreveu:2009/9/9 Glauco P. Gomes <glauco...@yahoo.com.br>:De forma totalmente automatica nao tem como resolver. Vc que vai ter que abrir e fechar a sessao.Se for assim então não faz sentido o container injetar EnityManager e gerenciar as transações... Melhor que eu faça tudo na unha mesmo. Pra quem vem do mundo desktop, esse HTTP é um retrocesso tecnológico afe.
Rafael Ponte
http://www.rponte.com.br
Danilo Magrini
>
> Vc pode utilizar Spring?
Pois é, eu não posso utilizar nada que não seja especificação. O Seam
fará parte da nova especificação, assim como o Facelets, mas até lá
não posso usar nada disso.
Aproveitando o assunto EJB, eu achei muito estranho essa de eu definir
em tempo de projeto o que será REMOTO e o que será LOCAL (falando de
Session Beans). Isso é ridiculo pois eu não sei o que será o que...
isso vai depender de N variáveis que inclusive podem mudar no decorrer
da vida do projeto. Outra coisa que eu achei estranho é o tal do
Persistent Unit.. ele tem que ser definido também em tempo de projeto?
E se Futuramente eu quiser ter 2 ou mais conexões? Ou quiser fazer
Login em Empresas diferentes que usam Persistent Units diferentes? Eu
tenho que criar outro dominio no servidor e fazer deploy de uma
aplicação inteira ali?? Sinceramente EJB3 ao meu ver não melhorou em
nada e Anotação só é viável pra sisteminha de locadora. Lamentável...
Danilo Magrini
> O Glauco, eu e mais alguns do grupo já discutimos numa thread sobre este
> assunto, até conversamos sobre detalhes mais interessantes e soluções. Se
> possível, aconselho que dêem uma olhada no histórico do grupo.
OK vou fazer a busca.
> Dica: Procure um framework que gerencie seus componentes de software (seja
> managed bean ou não). Como Spring ou mesmo JBoss Seam, pois JSF "puro" é
> praticamente um atraso de vida.
Pode ser... mas pelo menos não corro o risco de amanhã ter um sistema
legado por causa de um framework porco como aconteceu com o Struts.
grato.
Bruno Maomeh
Danilo Magrini
> salvo engano.. o Seam não fará parte especificação JSF.. será criada uma
> especificação nova, chamada de Web Beans, que será baseada no Seam.. igual
> ao jpa/hibernate.. :)
Foi o que eu quis dizer colega, senão eu não seria tão burro a ponto
de não estar usando o Seam.
Glauco P. Gomes
> Pode ser... mas pelo menos não corro o risco de amanhã ter um sistema
> legado por causa de um framework porco como aconteceu com o Struts.
crescendo muito em popularidade e principalmente em investimentos, na
minha opiniao, mesmo nao sendo uma especificacao/JSR, ele tambem veio
pra ficar.
E sobre especificacao/JSR, acho importante, mas temos especificacoes que
"morreram", veja o JDO, vc conhece alguem que o utiliza em novos projetos?
Existem outras especificacoes que não "vingaram", por isso nao confie
100% no que é especificado, o que segura mesmo um framework é sua
popularidade e sua evolucao.
O Struts por um motivo ou outro teve sua época, mas, talvez por falta de
investimento, nao evoluiu o suficiente para se manter no auge.
Glauco P. Gomes
Gilliard Cordeiro
Agora sobre alguns pontos que você comentou:
Aproveitando o assunto EJB, eu achei muito estranho essa de eu definir
em tempo de projeto o que será REMOTO e o que será LOCAL (falando de
Session Beans). Isso é ridiculo pois eu não sei o que será o que...
isso vai depender de N variáveis que inclusive podem mudar no decorrer
da vida do projeto.
Outra coisa que eu achei estranho é o tal do
Persistent Unit.. ele tem que ser definido também em tempo de projeto?
E se Futuramente eu quiser ter 2 ou mais conexões? Ou quiser fazer
Login em Empresas diferentes que usam Persistent Units diferentes? Eu
tenho que criar outro dominio no servidor e fazer deploy de uma
aplicação inteira ali??
Agora se a questão que você fala é usar instancias diferentes da mesma estrutura de banco na mesma instancia da aplicação, aí sim não sei como você poderia fazer sem usar algo não especificado como Seam ou Spring.
Usando esses caras você poderia "calcular" que EntityManager retornar baseado no perfil do usuário logado, por exemplo.
Nesse ponto volta a questão que vários de nós falamos aqui... usar JSF, JPA, EJB3, ou seja lá o que for "puro" é atraso de vida. É necessário um cara que saiba lidar com tudo isso junto como o Seam e Spring fazem.
Infelizmente se onde você trabalha só se usa o que é especificado, além de ter que esperar pelo "Java Context and Dependency Injection (JCDI)" (nome da especificação que antigamente se chamava WebBeans (esse vai ser o nome da implementação de referência, e não da especificação)), não vai poder usar extralazy do hibernate, cache de segundo nível e de query, vai ter que criar SelectItems e conversores para Entities na mão, e por aí vái...
Mas como eu disse antes, entendo que muitas vezes, principalmente em empresas maiores ou com clientes mais "exigentes", é complicado argumentar mesmo tecnicamente parecendo tão óbvio :-/
Danilo Magrini
> O Struts por um motivo ou outro teve sua época, mas, talvez por falta de
> investimento, nao evoluiu o suficiente para se manter no auge.
Assim como qualquer outro framework morra também seja qual for o
motivo. Pelo menos com especificação tenho a garantia de
compatibilidade com a evolução e vários outros benefícios.
Danilo Magrini
> O persistence unit é uma abstração do seu banco de dados. não vejo como você
> criar um novo banco e usar de forma "transparente" na sua aplicação sendo
> que ela inicialmente nem sabia que o banco existia.
Como não? Bastaria que anotações aceitasse uma váriavel no nome da PU
ao invés de ter que ser fixo. * Não precisa explicar como anotações
funcionam pois já li sobre isso e sei porque não podem ser dinamicas
*.
> Agora se a questão que você fala é usar instancias diferentes da mesma
> estrutura de banco na mesma instancia da aplicação, aí sim não sei como você
> poderia fazer sem usar algo não especificado como Seam ou Spring.
> Usando esses caras você poderia "calcular" que EntityManager retornar
> baseado no perfil do usuário logado, por exemplo.
?? teria como ?? O que eu quero é exatamente isso, baseado em algum
arquivo seja DB, seja XML, seja properties eu, mediante um parametro
(login ou qualquer outro), injetar a instância EM referente aquele
perfil, mas para isso eu teria que ter N (JNDIs, DataSources) de nomes
diferentes e N Persistent Units para poder mudar em Runtime. O que
hoje é impossível usando as ferramentas que tenho. Então o que você
está dizendo é que isso seria possível se eu usasse Spring e Seam?
> Nesse ponto volta a questão que vários de nós falamos aqui... usar JSF, JPA,
> EJB3, ou seja lá o que for "puro" é atraso de vida. É necessário um cara que
> saiba lidar com tudo isso junto como o Seam e Spring fazem.
Não é atraso de vida. De repente eu tenho um framework próprio e
interno onde eu resolva essas questões..
> vai ter que criar
> SelectItems e conversores para Entities na mão, e por aí vái...
Exato .. e é outra coisa que eu procurei exaustivamente e não
encontrei outra forma de fazer.
> Mas como eu disse antes, entendo que muitas vezes, principalmente em
> empresas maiores ou com clientes mais "exigentes", é complicado argumentar
> mesmo tecnicamente parecendo tão óbvio :-/
Pode ser óbvio hoje.. assim como era quando existia Struts. Mas
entendo seu ponto de vista.
Rafael Ponte
Não é atraso de vida. De repente eu tenho um framework próprio e
interno onde eu resolva essas questões..
Glauco P. Gomes
> Não é atraso de vida. De repente eu tenho um framework próprio e
> interno onde eu resolva essas questões..
>
testado e utilizado por milhares de empresas?
Não seria melhor utilizar um framework open source ja consagrado, e na
hipótese dele "morrer", vc manter um fork interno na sua empresa, do que
criar outro do "zero"?
Glauco P. Gomes
Gilliard Cordeiro
?? teria como ?? O que eu quero é exatamente isso, baseado em algum
arquivo seja DB, seja XML, seja properties eu, mediante um parametro
(login ou qualquer outro), injetar a instância EM referente aquele
perfil, mas para isso eu teria que ter N (JNDIs, DataSources) de nomes
diferentes e N Persistent Units para poder mudar em Runtime. O que
hoje é impossível usando as ferramentas que tenho. Então o que você
está dizendo é que isso seria possível se eu usasse Spring e Seam?
Sendo assim não vejo impedimento em calcular qual objeto EntityManager devolver assim como já faço com objetos de outros tipos.
> Nesse ponto volta a questão que vários de nós falamos aqui... usar JSF, JPA,
> EJB3, ou seja lá o que for "puro" é atraso de vida. É necessário um cara que
> saiba lidar com tudo isso junto como o Seam e Spring fazem.
Não é atraso de vida. De repente eu tenho um framework próprio e
interno onde eu resolva essas questões..
Então.... mas se não fosse atraso de vida você não precisaria de um framework próprio para lidar com essas questões, não é mesmo? Na verdade nós concordamos, a diferença é que eu uso um framework de mercado e você um próprio, mas ambos servem para fazer com que a utilização dessas coisas todas juntas se tornem produtivas.
Danilo Magrini
> Framework caseiro é a pior coisa que uma empresa pode investir hoje em dia.
> Fuja disso. Já existem N soluções para o mesmo problema e centenas de vezes
> melhor do que eu ou você poderiamos implementar num espaço de tempo e
> custo-benefício razoável.
Fale por você.
Danilo Magrini
> Então vc prefere desenvolver um framework proprio a utilizar um que é
> testado e utilizado por milhares de empresas?
Sim.
> Não seria melhor utilizar um framework open source ja consagrado, e na
> hipótese dele "morrer", vc manter um fork interno na sua empresa, do que
> criar outro do "zero"?
Creio que não pois não vou dar manutenção em códigos open-source, já
tive esse desprazer e posso te dizer que é a pior porquisse que
existe. Prefiro um interno pois ao menos consigo mantê-lo.
Danilo Magrini
> voce vai continuar tendo várias persistence units, mas para o seam e para o
> spring um entity manager nada mais é do que um componente associado ao seu
> contexto (componente seam no seam e spring no spring). E em ambos os
> frameworks você pode simplesmente dizer que um componente com tal nome vai
> ser uma instância de uma determinada classe associada a um determinado
> escopo ou entao retornar o objeto que representa esse componente a partir da
> execução de um método.
> Sendo assim não vejo impedimento em calcular qual objeto EntityManager
> devolver assim como já faço com objetos de outros tipos.
Provavelmente não vai dar certo, uma vez que meus Entities Manager são
injetados pelo container.
> Então.... mas se não fosse atraso de vida você não precisaria de um
> framework próprio para lidar com essas questões, não é mesmo? Na verdade nós
> concordamos, a diferença é que eu uso um framework de mercado e você um
> próprio, mas ambos servem para fazer com que a utilização dessas coisas
> todas juntas se tornem produtivas.
É bem isso... você se sente mais seguro usando os frameworks de
mercado e eu me sinto mais seguro usando o meu em vista de frameworks
que hora são "os 10 mais" e dias depois são "um lixo feito nas coxas".
Danilo Magrini
assunto e acabamos partindo para outras descussões. Agradeço a todos
pela boa vontade em me ajudar, creio que já defini o que vou fazer.
abraço a todos.
Rafael Meireles
quando a tecnologia ficar obsoleta, ambos ficaram...
Entao vc vai cair no mesmo caso.
--
Atenciosamente,
--------------------------------------------
Rafael Meireles Caetano
Desenvolvedor Java EE
Fone: +55 85 8811-1806
Danilo Magrini
> Frameworks sejam de mercado ou proprietarios (aka caseiro!)
> quando a tecnologia ficar obsoleta, ambos ficaram...
Discordo. Mas obrigado pelo comentário.
Rafael Ponte
Assim como no seu caso não parece haver restrição alguma a utilização de determinadas tecnologias, porém uma decisão tua quanto as soluções adotadas.
Somente alguns post sobre o assunto:
http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/
http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
http://www.rafaelcarneiro.net/blog/2008/05/23/frameworks-agindo-com-bom-senso/
Uma pesquisa rápida no Google ou mesmo em fóruns como GUJ te ajudarão a entender o mal do famigerado framework caseiro :-)
Um abraço e boa sorte.
Glauco P. Gomes
> Provavelmente não vai dar certo, uma vez que meus Entities Manager são
> injetados pelo container.
>
oferece uma API que permite vc obter a instancia de um Bean (no Spring
tudo é bean) através de seu nome.
Da uma estudada em como funciona o Spring e o Seam, mesmo se vc não for
utilizar, vc pode aproveitar algumas ideias, e implementar no seu framework.
Glauco P. Gomes
Glauco P. Gomes
Por traz do Spring e do Seam tem grandes empresas, e estas estão preocupadas com a manutenibilidade.
Não é pq é open-source que o projeto é uma coxa de retalhos, pelo contrário, se vc estudar um pouco a documentação do Spring (que é bem escrita e detalhada), vc vai ter pouca dificuldade para extende-lo.
Mesmo se vc esta decidido a não utilizar estes frameworks, vale a pena dar uma estudada na documentacao deles, para ver como eles funcionam, quem sabe vc não aproveita algumas ideias e utiliza no seu framework.
Glauco P. Gomes
Danilo Magrini escreveu:
2009/9/10 Glauco P. Gomes <glauco...@yahoo.com.br>:
Danilo Magrini
>
> Danilo Magrini escreveu:
>> Provavelmente não vai dar certo, uma vez que meus Entities Manager são
>> injetados pelo container.
realmente eles não precisam ser injetados, porém eu gostaria muito de
deixar que o container gerencie pra mim para evitar de ter qeu ficar
me preocupando com transação e open/close de entitymanager.
Danilo Magrini
Em que sentido?
> Por traz do Spring e do Seam tem grandes empresas, e estas estão preocupadas
> com a manutenibilidade.
Assim como era no Struts.
> Não é pq é open-source que o projeto é uma coxa de retalhos, pelo contrário,
> se vc estudar um pouco a documentação do Spring (que é bem escrita e
> detalhada), vc vai ter pouca dificuldade para extende-lo.
Então.. aqui já entra uma questão meio particular. Nos projetos que eu
já atuei (e tentei atuar) a documentação era uma coisa e a mão na
massa era oooooooutra coisa completamente diferente... parece óbvio,
mas você sabe sobre o que eu estou falando.
Mas entendi seu ponto de vista sim.
Glauco P. Gomes
2009/9/10 Glauco P. Gomes <glauco...@yahoo.com.br>:Entao open-source é tudo igual né?Em que sentido?
Glauco P. Gomes
Danilo Magrini
> Pelo visto não vale a pena argumentar sobre isso com você.
Dependendo do ponto de vista não mesmo.
> Assim como no seu caso não parece haver restrição alguma a utilização de
> determinadas tecnologias, porém uma decisão tua quanto as soluções adotadas.
Sim .. é isso. E se todos os frameworks fossem tão maravilhosos quanto
se mostram ser nunca haveria restrição de uso em nenhuma empresa,
setor ou qualquer coisa do genero.
> Somente alguns post sobre o assunto:
> http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/
> http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
> http://www.rafaelcarneiro.net/blog/2008/05/23/frameworks-agindo-com-bom-senso/
São nada mais do que opiniões e experiências pessoais que não
necessariamente serão verdadeiras em todos os projetos. Se eu tivesse
tempo e saco e poderia descrever as ótimas experiências que tive com
frameworks caseiros e as péssimas com frameworks "conceituados". Não
sei porque mas até me pareceu que em alguns trechos o pessoal não
enxerga bem a diferença de framework e conjunto de bibliotecas
próprias.
> Uma pesquisa rápida no Google ou mesmo em fóruns como GUJ te ajudarão a
> entender o mal do famigerado framework caseiro :-)
Ou o bem. Tudo depende de experiências passadas, do aprendizado
através dos erros e etc. Sinceramente tenho muitas saudades do
JSP/Servlet. Hoje temos que usar frameworks para ajudar a corrigir os
problemas que você não teria se não usasse frameworks.. vide JSF-EJB3
-> JSF-SEAM-EJB3
Mas obrigado ae Rafael e outros pela conversa pois eu creio que é aqui
que está a beleza do Open-Source: a opção de escolha (apesar de ter
saudades de quando não tinha escolha) lol
Gilliard Cordeiro
realmente eles não precisam ser injetados, porém eu gostaria muito de
deixar que o container gerencie pra mim para evitar de ter qeu ficar
me preocupando com transação e open/close de entitymanager.
> Por traz do Spring e do Seam tem grandes empresas, e estas estão preocupadas
> com a manutenibilidade.
Assim como era no Struts.
Struts foi há muito tempo, e de lá pra cá o que mudou mais foram as idéias de como fazer, e não a tecnologia. Se naquela época você tivesse feito um framework caseiro, provavelmente este não implementaria recursos modernos que frameworks como Seam e Spring implementam. No final das contas o frameworks seria teu, não estaria abandonado, mas teria que ser todo reinventado, o que dá quase na mesma de mudar de framework.
Eu entendo tua posição e não estou querendo te convencer a mudar de idéia, até porque na maioria das vezes isso não acontece. O ponto é que o que mais muda com o tempo não são os frameworks, e sim as formas de pensar na solução dos problemas.
Mas esse é meu ponto de vista, você tem o teu e outras pessoas aqui da lista têm outros. O bom da lista é coletar experiências e pontos de vista diferentes para aprendermos mais.
De qualquer forma, boa sorte.
Danilo Magrini
> No final das contas o
> frameworks seria teu, não estaria abandonado, mas teria que ser todo
> reinventado, o que dá quase na mesma de mudar de framework.
Opa! Entendeu realmente o que eu estou tentando dizer! Agora a
afirmação final "o que dá quase na mesma de mudar de framework." que
faz toda a diferença? Será mesmo que da quase na mesma? Acho que só o
tempo dirá mesmo.
alecindro
Login em empresas diferentes? Que tem a ver isso com a Persistence Unit?
Cada aplicação tem seus ejb's com suas persistences units. Os ejb's de uma
empresa será acessado remotamente (ou não) pela que quer consumir esse
serviço.
A forma como cada uma implementa o Login (exemplo dado por você) isso é
particular da aplicação. A outra aplicação vai apenas acessar o serviço
disponibilizado,
independente como foi implementa a persistência. A quantidade de conexões
você vai configurar no servidor de aplicações, que é o responsável por isso
(pool de conexões).
--------------------------------------------------
From: "Danilo Magrini" <danilo....@gmail.com>
Sent: Thursday, September 10, 2009 9:00 AM
To: <jav...@googlegroups.com>
Subject: [javasf] Re: Se da erro, então pra que serve o LAZY?
>
> 2009/9/9 Glauco P. Gomes <glauco...@yahoo.com.br>:
>> Outra coisa, vc realmente precisa de EJBs? Sua aplicacao é distribuida?
>>
>> Vc pode utilizar Spring?
>
> Pois é, eu não posso utilizar nada que não seja especificação. O Seam
> fará parte da nova especificação, assim como o Facelets, mas até lá
> não posso usar nada disso.
> em tempo de projeto o que será REMOTO e o que será LOCAL (falando de
> Session Beans). Isso é ridiculo pois eu não sei o que será o que...
> isso vai depender de N variáveis que inclusive podem mudar no decorrer
> E se Futuramente eu quiser ter 2 ou mais conexões? Ou quiser fazer
> Login em Empresas diferentes que usam Persistent Units diferentes? Eu
> tenho que criar outro dominio no servidor e fazer deploy de uma
Danilo Magrini
>
> Danilo não deu para entender o que você disse.
> Login em empresas diferentes? Que tem a ver isso com a Persistence Unit?
É extenso demais eu tentar te explicar assim digitando, agradeço a atenção.