Una delle prime cose che ho imparato sullo sviluppo di Java EE è che non dovrei generare i miei thread all'interno di un contenitore Java EE. Ma quando ci penso, non ne conosco il motivo.

Puoi spiegare chiaramente perché è scoraggiato?

Sono sicuro che la maggior parte delle applicazioni aziendali necessita di qualche tipo di lavoro asincrono come daemon di posta, sessioni inattive, lavori di pulizia ecc.

Quindi, se davvero non si dovrebbero generare thread, qual è il modo corretto per farlo quando necessario?

È sconsigliato perché tutte le risorse all'interno dell'ambiente devono essere gestite e potenzialmente monitorate dal server. Inoltre, gran parte del contesto in cui viene utilizzato un thread è in genere collegato al thread di esecuzione stesso. Se avvii semplicemente il tuo thread (che credo che alcuni server non consentano nemmeno), non sarà possibile accedere ad altre risorse. Ciò significa che non è possibile ottenere un InitialContext ed eseguire ricerche JNDI per accedere ad altre risorse di sistema come JMS Connection Factories e Datasources.

Ci sono modi per farlo "correttamente", ma dipende dalla piattaforma utilizzata.

Commonj WorkManager è comune a WebSphere e WebLogic e ad altri

Maggiori info qui

E qui

Anche in qualche modo duplica questo di questa mattina

AGGIORNAMENTO: Si prega di notare che questa domanda e risposta si riferiscono allo stato di Java EE nel 2009, le cose sono migliorate da allora!

Per i bean EJB, non solo è sconsigliato, ma è espressamente vietato dalle specifiche :

Un bean enterprise non deve utilizzare primitive di sincronizzazione dei thread per sincronizzare l'esecuzione di più istanze.

e

Il bean enterprise non deve tentare di gestire i thread. Il bean enterprise non deve tentare di avviare, arrestare, sospendere o riprendere un thread o di modificare la priorità o il nome di un thread. Il bean enterprise non deve tentare di gestire i gruppi di thread.

Il motivo è che gli EJB devono funzionare in un ambiente distribuito. Un bean potrebbe essere spostato da una macchina in un cluster a un'altra. Thread (e socket e altre strutture limitate) sono un ostacolo significativo a questa portabilità.

Il motivo per cui non dovresti generare i tuoi thread è che questi non saranno gestiti dal contenitore. Il contenitore si occupa di molte cose che uno sviluppatore inesperto può trovare difficile immaginare. Ad esempio, cose come il pool di thread, il clustering, i ripristini di arresto anomalo vengono eseguiti dal contenitore. Quando avvii un thread potresti perderne alcuni. Inoltre, il contenitore consente di riavviare l'applicazione senza influire sulla JVM su cui viene eseguita. Come sarebbe possibile se ci fossero thread fuori dal controllo del contenitore?

Questo è il motivo per cui da J2EE 1.4 sono stati introdotti i servizi di timer. Vedi questo articolo per i dettagli.

Utilità di concorrenza per Java EE

Ora esiste un modo standard e corretto per creare thread con l'API Java EE principale:

• JSR 236: utilità di concorrenza per Java ™ EE

Utilizzando Concurrency Utils, ti assicuri che il tuo nuovo thread sia creato e gestito dal contenitore, garantendo che tutti i servizi EE siano disponibili.

Esempi qui

Puoi sempre dire al contenitore di avviare qualcosa come parte dei tuoi descrittori di distribuzione. Questi possono quindi svolgere tutte le attività di manutenzione che devi fare.

Segui le regole. Sarai felice di averlo fatto un giorno :)

I thread sono vietati nei contenitori Java EE in base ai modelli. Fare riferimento ai progetti per ulteriori informazioni.

Non c'è una vera ragione per non farlo. Ho usato Quarz con Spring in una webapp senza problemi. java.util.concurrentPuò essere utilizzato anche il framework di concorrenza . Se si implementa la propria manipolazione del filo, impostare i theads al demone o utilizzare un proprio gruppo di thread demone per loro in modo che il contenitore può scaricare il vostro webapp in qualsiasi momento.

Ma attenzione, la sessione e la richiesta dei bean scopes non funzionano nei thread generati! Inoltre, altri codici inseriti ThreadLocalnon funzionano immediatamente , è necessario trasferire i valori ai thread generati da soli.

Non ho mai letto che sia scoraggiato, tranne per il fatto che non è facile da fare correttamente.

È una programmazione di livello abbastanza basso e, come altre tecniche di basso livello, dovresti avere una buona ragione. La maggior parte dei problemi di concorrenza può essere risolta in modo molto più efficace utilizzando costrutti incorporati come i pool di thread.

Una ragione per cui ho scoperto che se si generano alcuni thread in EJB e poi si tenta di scaricare il contenitore o aggiornare il proprio EJB, si verificano problemi. C'è quasi sempre un altro modo per fare qualcosa in cui non hai bisogno di un thread, quindi dì semplicemente NO.