A espec. JEE não me permite usar threads para processamento paralelo.
Creio que uma solução seja usar filas JMS com MDB.
Mas como meu caso é bem simples, eu queria evitar de ter que usar JMS e MDB, pois só preciso de um ServletContextListener que executa algo. Esse algo é meio demorado e acaba travando o startup do Jboss ou do contexto.
Como essa minha implementação vai em diversos sistemas, na forma de um JAR, quero simplificar e fazer algo com processamento paralelo, tudo dentro de um jar, que pode ser usado dentro de cada app web, sem um precisar criar dependências externas ou mais complicadas.
Você não pode fazer o seu ServletContextListener disparar uma Thread não?!?!
Cria uma classe que extende Thread (ou implementa Runnable :D) e no listener você dá um thread.start() nessa classe que você criou!
Bem… espero ter ajudado. Abraço.
agodinho
vc não queria dizer assíncrono não?
Woody
urubatan
danieldestro:
Caros,
A espec. JEE não me permite usar threads para processamento paralelo.
Creio que uma solução seja usar filas JMS com MDB.
Mas como meu caso é bem simples, eu queria evitar de ter que usar JMS e MDB, pois só preciso de um ServletContextListener que executa algo. Esse algo é meio demorado e acaba travando o startup do Jboss ou do contexto.
Como essa minha implementação vai em diversos sistemas, na forma de um JAR, quero simplificar e fazer algo com processamento paralelo, tudo dentro de um jar, que pode ser usado dentro de cada app web, sem um precisar criar dependências externas ou mais complicadas.
O que sugerem?
de dentro do listener tu pode usar threads, de dentro de um request de um servlet que não pode pela especificação
danieldestro
Bom saber… e vc sabe o pq pode em um e nao em outro?
urubatan
Bom saber… e vc sabe o pq pode em um e nao em outro?
o listener starta na “thread principal” da tua aplicação.
a resposta a um request roda dentro de uma thread criada só pra isto, por isto o tratamento das duas coisas é diferente.
por exemplo, se tu colocar um sleep dentro de um ServletContextListener, o servidor vai parar o startup dele e ficar esperando a volta do teu sleep para continuar o processamento.
se tu fizer a mesma coisa dentro de um metodo “doGet” por exemplo, ele não vai travar.
o “não pode criar threads” vem do pressuposto de que o container vai criar uma thread para atender a cada request dos usuários, e ele tem que cuidar do ciclo de vida destes threads, como tu não deve trancar um thread destes, para tentar sincronizar com o teu, se tu criar um thread ali dentro este ficaria perdido …
é só este o problema.
danieldestro
Resolvido com as classes java.util.Timer e java.util.TimerTask.
Me parece melhor que usar Threads.
louds
danieldestro:
Resolvido com as classes java.util.Timer e java.util.TimerTask.
Me parece melhor que usar Threads.
Que internamente usam threads.
Se o teu servidor de aplicação suportar a spec commonj, já tem um WorkManager que te permite realizar processamento assíncrono usando threads gerenciadas pelo container.
