Perché i thread di spawning nel contenitore Java EE sono scoraggiati?

Question

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 arrivo a pensarci, non ne conosco il motivo.

Puoi spiegare chiaramente perché è scoraggiato?

Sono sicuro che la maggior parte delle applicazioni aziendali hanno bisogno di un qualche tipo di job asincroni come demoni di posta elettronica, le sessioni inattive, posti di lavoro di pulizia ecc

Quindi, se davvero non si dovrebbe generare discussioni, qual è il modo corretto per farlo Quando necessario?

Answer 1

È 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 si avvia semplicemente una propria discussione (che credo che alcuni server non consentono nemmeno), non può accedere ad altre risorse. Ciò significa che non è possibile ottenere un InitialContext e fare ricerche JNDI per accedere ad altre risorse di sistema, ad esempio Factories e origini dati di JMS Connection.

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

The commonj WorkManager is common for WebSphere and WebLogic as well as others

More info here

And here

po duplica anche this one da questa mattina

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

Answer 2

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

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

Answer 3

Il motivo per cui non è necessario generare i propri thread è che questi non saranno gestiti dal contenitore. Il contenitore si prende cura di molte cose che uno sviluppatore inesperto può trovare difficile da immaginare. Ad esempio cose come il pool di thread, il clustering, i ripristini di crash vengono eseguiti dal contenitore. Quando inizi una discussione 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 fili fuori dal controllo del contenitore?

Questa è la ragione per cui sono stati introdotti servizi timer J2EE 1.4. Vedere l'articolo this per i dettagli.

Answer 4

Non c'è un vero motivo per non farlo. Ho usato Quarz con Spring in una webapp senza problemi. Può essere utilizzato anche il framework di concorrenza java.util.concurrent. Se implementi la tua gestione dei thread, imposta i thead su deamon o usa un proprio gruppo thread deamon per loro in modo che il contenitore possa scaricare la tua webapp in qualsiasi momento.

Ma attenzione, il fagiolo ambiti sessione e richiesta non funzionano in discussioni deposto le uova!Anche l'altro codice prodotto su ThreadLocal non funziona immediatamente, è necessario trasferire da sé i valori ai thread generati.

Answer 5

È sempre possibile indicare al contenitore di avviare i materiali come parte dei descrittori di distribuzione. Questi possono quindi eseguire qualsiasi attività di mantenimento che è necessario eseguire.

Seguire le regole. Un giorno l'avrai fatto :)

Answer 6

Una ragione per cui ho trovato se si generano alcuni thread in EJB e quindi si tenta di scaricare o aggiornare il bean che si verificherà nei problemi. C'è quasi sempre un altro modo di fare qualcosa in cui non hai bisogno di una discussione, quindi basta dire NO.

Answer 7

Per bean, non è solo scoraggiato, è espressamente vietato dalla specification:

Un bean enterprise non deve usare filo primitive di sincronizzazione per sincronizzare esecuzione di molteplici istanze.

e

Il fagiolo di impresa non deve tentare per gestire le discussioni. Il bean enterprise non deve tentare di avviare, arrestare, sospendere o riprendere una discussione o su modificare la priorità o il nome di un thread. Il bean enterprise non deve tentare per gestire i gruppi di thread.

La ragione è che gli EJB sono pensati per operare in un ambiente distribuito. Un EJB potrebbe essere spostato da una macchina in un cluster a un'altra. I fili (e le prese e altre strutture vietate) rappresentano un ostacolo significativo a questa portabilità.

Answer 8

I thread sono vietati nei contenitori Java EE in base ai progetti. Si prega di fare riferimento allo blueprints per ulteriori informazioni.

Answer 9

Concorrenza Utilità per Java EE

Ora c'è uno standard, e il modo corretto per creare filettature con l'API nucleo Java EE:

• JSR 236: Concurrency Utilities for Java™ EE

Utilizzando concorrenza Utils, ci si assicura che il nuovo thread sia creato e gestito dal contenitore, garantendo che tutti i servizi EE siano disponibili.

Esempi here