Quais vantagens de se usar @RequestScoped ao invés de @PrototypeScoped em classes @Component?

Assuntos Gerais
#1

Se o Controller sempre é criado nas requisições, por que não é melhor usar o @PrototypeScoped em Daos?
Já que ele vai ser criado na hora da requisição.

No meu caso eu preciso de um DAO numa thread(ainda estou pensando se vou usar algum framework para isso), mas a Thread é @ApplicationScoped, então não tem como eu pegar um @Component @RequestScoped. E ficar instanciando na mão é complicado, pois eu preciso de vários DAO’s.

#2

Acho que já entendi o porquê de não usar o @PrototypeScoped no meu caso.

Se eu não estiver enganado, se eu tiver 3 daos na minha requisição, eles compartilham o mesmo EntityManager do JPA criado, certo?
E se eu fosse usar o @PrototypeScoped eu teria um EntityManager para cada DAO.

#3

Está certo, cada um vai ter o seu entity manager.

Mas eu acho que é ai que você DEVE usar o Prototype. Pois você pode ter sujeira de um DAO para outro.

#4

[quote=Rafael Guerreiro]Está certo, cada um vai ter o seu entity manager.

Mas eu acho que é ai que você DEVE usar o Prototype. Pois você pode ter sujeira de um DAO para outro.[/quote]

Você sabe no que o EntityManager poderia ficar sujo?

Pois eu tenho um interceptor que inicia e fecha a Transaction, e caso alguma Exceção aconteça o interceptor chama o método rollback. E se eu usar o @PrototypeScoped, eu terei que gerenciar isso no próprio dao.

#5

Então, eu tive uns problemas nesse sentido.

Aparentemente, se você usar a mesma Session em todos os DAOs, ele carrega as transações já commitadas ou com rollback e tenta refazê-las num próximo commit…

Eu sei de um comando para limpar a session: session.clear();

Se você usá-lo, não precisa ser @Prototype…

#6

na verdade se o dao é @Prototype, mas o EntityManager é @Request, os daos vão compartilhar o mesmo EM na mesma requisição.

então não tem problema o dao ser prototype, isso só significa que cada classe que recebe o dao vai ter uma cópia diferente dele…

agora se vc receber esse dao num componente @ApplicationScoped ele não vai funcionar corretamente pq ele tá segurando uma referencia a um EntityManager pendurado numa request.

Dá pra resolver essa dependência no Guice recebendo um Provider, ao invés do entityManager direto… assim cada vez que vc precisar dele ele pega o entityManager da request atual… só daria pau se for executado fora de request.

#7