[quote]
O Spring possui um escopo chamado prototype que define que o componente terá uma nova instância sempre que for requisitada… Este escopo serve para definir compenentes utilizados por tasks em escopo de application que naturalmente não são singletons, como DAO?s.
Deste modo, será criado uma instância do seu DAO para cada requisição de instância (lê-se: sempre que você receber uma instância pelo construtor, será uma nova), assim como uma Session separada.
[/quote][/quote]
“Este escopo serve para definir compenentes utilizados por tasks em escopo de application”
entao como tinha dito anteriormente eu preciso desse muitas vezes no escopo de request em diversos ponto do programa nao vou recriar um componente pra cadas escopo pra repetir código…tem como falar que um componente pode estar em dois escopos ao mesmo tempo?? no caso no escopo prototyped e request??
Cara num é que era o close da factory mesmo…rodei o profiler aki de novo com as alterações…pq dificilmente ele iria entrar no exception do close do printwriter…agora com o profiler se mantem estavel em 108 megas…e 11 threads…
isso rodando de 10 em 10 segundos…o que seria pra estressar o ambiente mesmo…e a carga se mantem…
Obrigado pela paciencia e ajuda de voces…vo voltar o eskema pra rodar no produção com esse close que faltou…
Antes de minha barba ficar branca, eu aprendi isso com um amigo muito experiente:
Sempre procure metodos close(), quit(), finalize(), release() , etc nestes objetos de frameworks e na propria api java, quando os utilizar. Pois isso salva fim de semana.
[quote=CarvalR2]Antes de minha barba ficar branca, eu aprendi isso com um amigo muito experiente:
Sempre procure metodos close(), quit(), finalize(), release() , etc nestes objetos de frameworks e na propria api java, quando os utilizar. Pois isso salva fim de semana.
(e vale muito para mes de copa do mundo)
Fico feliz em repassar esse conhecimento. Até +[/quote]
É entao eu ja tinha mudado o eskema desse scheduler pra nao ficar de barba branca…kkkk…como disse pra uma maneira menos portavel mas que resolveu…
…mas sou de ir atras o porque nao estava funcionando…agora vou ficar mais esperto…com esse tipo de coisa ou seja quando eu “o programador burraldo fizer as coisas” realmente escapou akele close fiquei tão preocupado em fechar a session que esqueci da factory…
Já que o culpado inicial de tudo foi aquele componente que está no cookbook minha sugestão é retira-lo e notificar o autor. Logo vamos ter uma sindrome de “out-of-memory” de tanta gente fazendo copy and paste de código bugado.
Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?
Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.
Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?
Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.
Se estiver equivocado, por favor me informe.[/quote]
Tá certo, acabei não lendo com atenção o tópico e falei besteira :oops:
Olhei com calma a sugestão do cookbook e realmente me parece que está tudo certo, visualmente falando. Os objetos que teriam problema em criar multiplas instâncias e não fechar estão todos como application-scoped. Me parece certo mesmo.
Voce está falando do Job Scheduling com Vraptor e Spring que está no livro de receitas?
Eu tenho uma bagagem muito pequena em java, mas esse artigo me parece muito bom e pelo que vi o Boneazul implementou de uma forma diferente da recomendada no artigo. Poderia tentar testar a solução sugerida, estou com pouco tempo mas posso tentar agendar.
Se estiver equivocado, por favor me informe.[/quote]
Tá certo, acabei não lendo com atenção o tópico e falei besteira :oops:
Olhei com calma a sugestão do cookbook e realmente me parece que está tudo certo, visualmente falando. Os objetos que teriam problema em criar multiplas instâncias e não fechar estão todos como application-scoped. Me parece certo mesmo.[/quote]
o componente esta ok sim…o erro foi da implementacao que faltou fechar a Sessionfactory por isso dava o vazamento de memória…é q na epoca nao havia tambem o suporte a prototypedScope no vraptor…que hoje tem…
mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…
com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??
[quote=boneazul]mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…
com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??[/quote]
Não, você não pode injetar um requested-scope em um application scoped. Mas o contrário você pode.
Isso, a principio, me parece um erro de lógica. Mas pensando bem não vejo um problema nisso, e até o EJB permite você fazer isso, já que em um EJB Scheduler do 3.1 eu tenho stateless session beans injetados em um scheduler.
mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…
com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??
[/quote]
Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.
A observação do Garcia é interessante. Talvez permita uma solução mais simples.
mas para o meu caso ainda ta complicado injetar o dao la dentro pq eu uso o dao tanto no escopo de request e o scheduler que fica no escopo de aplicação nao consegue injetar…
com eu faria pra injetar o dao nesse escopo sem ter que criar uma classe igualzinha nessse escopo…tem jeito??
[/quote]
Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.
A observação do Garcia é interessante. Talvez permita uma solução mais simples.[/quote]
A solução que voce dizem é passar o dao para @ApplicationScoped??
[quote=boneazul][quote=Lagaffe]Tambem acho que não é possível. Fiquei com a mesma dúvida, mas me pareceu que qualquer solução ficaria mais complexa que duplicar o(s) dao(s). Pelo menos no sistema que estamos desenvolvendo aqui.
A observação do Garcia é interessante. Talvez permita uma solução mais simples.[/quote]
A solução que voce dizem é passar o dao para @ApplicationScoped?? [/quote]
Pois é, não entendo bem qual a diferença, isso a nivel de dao, de ser application. Se pensar no EJB, um stateful não deixa de ser um application scoped. Mas isso o Lucas que pode opinar melhor.
O problema seria você ter um session como atributo de classe, porém creio que se a session segue a idéia do entity-manager isso não será problema.