EJB 3.0 + Threads

Vc quer criar threads para que?

Pq dependendo do que vc quer fazer o Container já cuida disso pra vc.

O que exatamente você quer fazer?

Porque pelo que eu sei, é o container que ficará responsável por fazer o controle de threads das chamadas aos Sessions, Messages Bean and Entities.

Eu tenho algumas threads que coletam informações de varias coisas.
Eu gostaria de uma aplicação web fazer a chamada a um EJB e este ejb executar essas threads.
Porque ai eu usaria o quartz para agendar a chamada desses EJB e eles executariam as threads para mim.

No caso não são threads que chamam os ejb, pq isso o container controlaria. E sim na execução do EJB executar
as threads.

Grato.

A especificação não recomenda que vc faça isso.
Alguns container levam isso ao pe da letrae nao permitem. Outros precisam ser inicializados com algum parametro indicando que vc vai poder criar threads.

[]´s

E porque TEM que ser EJB isso ai? Qual é a real necessidade?

Mas como disse o Jair, use o controle do container para gerenciar seus EJBs, é mais seguro/fácil que fazer tudo na mão.

A necessidade é essa :

Por exemplo o quatz vai fazer 100 chamadas a um objeto (EJB ou Outro(Caso vcs tenham uma sugestão)) a cada 5 minutos, e esses objetoss vão executar cerca de 30 a 50 threads que fazem a coleta da informação, ai eu gravo o resultado no banco de dados.

Com EJB sem estado, eu teria um pool então num precisaria ter muitos objetos em memoria, para gravar no banco eu teria recursos de transação.
E conseguiria manter isso rodando em servidores diferente, até configurar um cluster com o jboss caso as requisições aumentem !!!

Que acha ?

Ao invés de usar o Quartz para agendar as chamadas ao EJB, porque você não usa o EJB Timer?
(Não sei exatamente qual a sua necessidade, porém um amigo meu aqui do serviço utilizou o EJB Timer em uma tarefa que deveria ser executada a cada X minutos e funcionou muito bem).

Assim, creio eu, que você pode deixar tudo a cargo do próprio container.

Bom ai depende…as coletas de informação tem que rodar em paralelo?

Eu estou usando o Quartz, porque fiz algumas pesquisas e o quartz foi melhor recomendado que o timer do ejb, e tambem porque o quartz tem um otimo esquema de agendamento baseado na cron…

J_Junior:

A necessidade é essa :

Por exemplo o quatz vai fazer 100 chamadas a um objeto (EJB ou Outro(Caso vcs tenham uma sugestão)) a cada 5 minutos, e esses objetoss vão executar cerca de 30 a 50 threads que fazem a coleta da informação, ai eu gravo o resultado no banco de dados.

Com EJB sem estado, eu teria um pool então num precisaria ter muitos objetos em memoria, para gravar no banco eu teria recursos de transação.
E conseguiria manter isso rodando em servidores diferente, até configurar um cluster com o jboss caso as requisições aumentem !!!

Que acha ?

Existe um problema. Você está com várias threads compartilhando uma transação no banco de dados, e me parece um problema. Primeiro, porque nunca ouvi falar que Connection ou DataSource são thread-safe (e por isso assumo que não são). E segundo, porque, mesmo que fossem thread-safe, você está querendo que 50 “caras” acessem um ÚNICO recurso, o que causaria muitos locks e minaria qualquer vantagem em espalhar em várias threads.

Se eu fosse você adotaria as seguintes alternativas:
1- Esqueça threads :arrow: se você viu que o tempo de processamento é aceitável, faça tudo linearmente e se livre de todos os problemas;

2- Esqueça transações, esqueça ACID :arrow: cada thread abre manualmente uma conexão (ou obtém uma de um DataSource), faz suas coisas, comita e fecha. Assim, você se livra de uma thread compartilhar recursos com outra. Você pode tentar criar planos de contingência, do tipo: se não conseguir inserir na base, cria-se logs que pode ser realimentado pelo sistema mais tarde.

3- Esqueça gerenciadores de banco de dados relacionais :arrow: eles não foram pensados para um mundo concorrente, existem bancos de dados orientados a documentos pensados para serem distribuídos. Se você pode correr esse risco, avalie essa alternativa.

Leonardo3001 , não tenho alternativa a não ser usar threads, as coletas tem que acontecer em paralelo, não pode ser linear.
Outra coisa eu não estou abrindo um datasource nem uma conexão por thread…hoje em dia eu tenho uma classe
que cria as threads , então as threads coletam e inserem isso num pool de resultados, e aos poucos outra classe
pega esse pool, abre uma conexão insere tudo e fecha !!!

J_Junior:

Leonardo3001 , não tenho alternativa a não ser usar threads, as coletas tem que acontecer em paralelo, não pode ser linear.
Outra coisa eu não estou abrindo um datasource nem uma conexão por thread…hoje em dia eu tenho uma classe
que cria as threads , então as threads coletam e inserem isso num pool de resultados, e aos poucos outra classe
pega esse pool, abre uma conexão insere tudo e fecha !!!

Vixi!

É só isso? Mamão com mel! A classe que vai criar várias threads não é um Session Bean, é uma classe normal. Quando você tiver um pool completo, coloca-o como parâmetro de um método em uma outra classe Session Bean, que irá inserir no banco de dados.