Quando utilizo qualquer método de persistencia no banco Oracle10g ele não realiza a modificação…
ele não retorna erro da aplicação …o debug do hibernate imprime
jdbc : commit
jdbc : commited
mas não é realizado…
por padrão o vraptor da o session.close() usando esse tipo de escopo??
pois pelo que vi o hibernatecustomprovider fica em escopo de request …alguma ideia???
Onde está sua transação? Onde você faz um flush? E onde você fecha a session? O Vraptor por sí próprio não vai fazer nada porque você está injetando a SessionFactory. O correto é usar a Session.
Porque ao invés de reinventar a coisa você não usa o componente do Vraptor que faz todo esse controle de abrir/fechar sessions e transaction?
Lucas_Cavalcanti
Qual é o motivo pra esse dao ser Prototype?
a regra é: se você abriu a sessão, você fecha…
ou seja, se a ConfiguracaoDao abriu, ela fecha. Possivelmente criar uma metodo close() anotado com @PreDestroy funcione… não sei se isso rola no @PrototypeScoped, mas nos outros escopos sim…
e de qqer forma, pra modificar coisas do banco, a operação deve estar dentro de uma transação, senão não acontece nada
boneazul
garcia-jj:
Onde está sua transação? Onde você faz um flush? E onde você fecha a session? O Vraptor por sí próprio não vai fazer nada porque você está injetando a SessionFactory. O correto é usar a Session.
Porque ao invés de reinventar a coisa você não usa o componente do Vraptor que faz todo esse controle de abrir/fechar sessions e transaction?
Ja estou usando o HibernateCustomProvider.Não estou “reinventando a coisa”…preciso de @prototyped scope pq utilizo dao numa job scheduler…e nao consigo injetar componente em escopo de request no caso essa DAO…
boneazul
Lucas Cavalcanti:
Qual é o motivo pra esse dao ser Prototype?
a regra é: se você abriu a sessão, você fecha…
ou seja, se a ConfiguracaoDao abriu, ela fecha. Possivelmente criar uma metodo close() anotado com @PreDestroy funcione… não sei se isso rola no @PrototypeScoped, mas nos outros escopos sim…
e de qqer forma, pra modificar coisas do banco, a operação deve estar dentro de uma transação, senão não acontece nada
Bom o motivo dele ser prototyped é de poder injetar ele em um componente job scheduler…que fica em escopo de application…a injecao funciona sem o spring reclamar…so que fica esse problema do close…
Bom como estou usando o componente de voces o “HibernateCustomProvider” ele ja nao usa por padrão a abertura e fechamento da transação com o HibernateTransactionInterceptor ?? ou so faz isso em escopo de request??
Tentei criar um @preDestroy num metodo chamado close do dao mas ele nunca é chamado …alguma ideia de como fazer um close dessa session???
boneazul
Bom resolvi de um modo bem feio viu …tendo que abrir e fechar transação na mão e a session tb.
Teria outro jeito mais elegante ja que utilizo diversos componentes com a anotação @prototyped nas tarefas agendadas???
Lucas_Cavalcanti
esses daos anotados com @PrototypeScoped são usados só nas tarefas agendadas, ou em todo o sistema?
boneazul
todo o sistema…ou seja …ele teria que rodar na aplicação em escopo de request e teria que ser reaproveitado nas tarefas agendadas…
Lucas_Cavalcanti
um jeito fácil de fazer é:
deixe todos os seus daos request scoped mesmo
crie um componente assim:
@Component@ApplicationScopedpublicclassDaoManager{// ou interface-implementação se preferirprivateMap<Dao,Session>daos=newHashMap<...>();// ou alguma abstração dissopublicDaoManager(SessionFactoryfactory){this.factory=factory;}public<TextendsDao>TcreateDao(Class<T>daoType){//abre uma sessao//abre uma transacao//instancia o dao//coloca o dao no mapa, ligado com a sessao dele (talvez com a transacao tb, se vc criar uma classe que engloba isso)//retorna o dao}publicvoiddestroyDao(Daodao){//pega a sessao do dao no mapa//commita ou dá rolllback na transacao//fecha a sessao}}
e na tarefa agendada vc usaria o DaoManager abrindo e fechando o dao
existem várias maneiras de melhorar isso…
outros jeitos envolvem criar aspectos, proxies, ou coisas do tipo
boneazul
Lucas Cavalcanti:
um jeito fácil de fazer é:
deixe todos os seus daos request scoped mesmo
crie um componente assim:
@Component@ApplicationScopedpublicclassDaoManager{// ou interface-implementação se preferirprivateMap<Dao,Session>daos=newHashMap<...>();// ou alguma abstração dissopublicDaoManager(SessionFactoryfactory){this.factory=factory;}public<TextendsDao>TcreateDao(Class<T>daoType){//abre uma sessao//abre uma transacao//instancia o dao//coloca o dao no mapa, ligado com a sessao dele (talvez com a transacao tb, se vc criar uma classe que engloba isso)//retorna o dao}publicvoiddestroyDao(Daodao){//pega a sessao do dao no mapa//commita ou dá rolllback na transacao//fecha a sessao}}
e na tarefa agendada vc usaria o DaoManager abrindo e fechando o dao
existem várias maneiras de melhorar isso…
outros jeitos envolvem criar aspectos, proxies, ou coisas do tipo