Implementazione della concorrenza nell'applicazione Web Java EE

Question

Stiamo creando un'app Web in cui è necessario disporre della concorrenza per alcuni casi aziendali. Questa applicazione verrebbe distribuita in un contenitore Tomcat. So che creare thread definiti dall'utente nel contenitore web è una cattiva idea e sto cercando di esplorare le opzioni che ho.

1. La mia libreria multi-thread utilizzata come componente JCA. Siamo contrari all'utilizzo di questo approccio a causa della curva di apprendimento che potrebbe essere coinvolta.
2. So che sono disponibili le API di WorkManager ma suppongo che questo non sia implementato da tomcat, quindi questa opzione si spegne.
3. Ho fatto qualche ricerca e ho scoperto che la libreria CommonJ è consigliata per Tomcat. Qualcuno l'ha usato?
4. Inoltre, vedo che sono disponibili ManagedExecutorService ma non sono sicuro di come utilizzarlo ed è diverso dalle API di WorkManager (e dalla libreria commonJ)?

Qualsiasi aiuto su questo apprezzato. A proposito, usare JMS è fuori discussione a causa dell'ambiente di distribuzione. Sono incline ai punti 3 e 4 ma non ho molta conoscenza in merito. Qualcuno potrebbe guidare pls.

Answer 1

Dato che stai utilizzando Tomcat, non preoccuparti e fai quello che vuoi. La sezione Servlet di Java EE non fa menzione di thread ecc. Questo è principalmente nella sezione EJB.

Tomcat in sé non fa molto per preoccuparsi della gestione dei thread, è un contenitore piuttosto non invasivo.

È meglio legare i thread a un ServletContextListener in modo da poter prestare attenzione al ciclo di vita dell'applicazione e arrestare i file quando si chiude l'applicazione, ma oltre a ciò, non preoccuparsi eccessivamente di ciò e utilizzare qualsiasi cosa sono felice con.

Addenda -

La semplice verità è Tomcat non si cura, e non è così sofisticato. Tomcat dispone di un pool di thread per ciascun listener HTTP e si tratta della fine del suo livello di gestione. Tomcat non prenderà i thread da un ascoltatore HTTP silenzioso e li dedicherà a uno occupato, ad esempio. Se Tomcat fosse veramente interessato a come si creano i thread, ciò impedirebbe di farlo, e non è così.

Ciò significa che la gestione dei thread al di fuori del contesto HTTP ricade direttamente sulle spalle come implementatore. Java EE espone questo tipo di funzionalità e le interfacce offrono letture eccezionali. Ma la semplice verità è che le capacità teoriche sposate dai documenti Java EE API e la realtà delle implementazioni moderne è molto diversa, in particolare nei sistemi di fascia bassa come Tomcat.

Non denigrare Tomcat. Tomcat è un ottimo software. Ma per la maggior parte dei casi d'uso, la capacità di gestione extra semplicemente non è necessaria.

Configurare il proprio pool di thread (utilizzando le strutture fornite da JDK) e lavorare con il proprio modello di ciclo di vita del thread probabilmente vi vedrà correttamente attraverso qualunque progetto stiate lavorando. Non è davvero un grosso problema.

Answer 2

Ogni servlet - componente base Java EE per l'elaborazione delle richieste HTTP - nell'applicazione Web è un Singleton e ogni richiesta viene eseguita con il proprio thread indipendente, quindi non è necessario avviare/interrompere i thread generati dall'utente da soli. Il tuo contenitore Web, in questo caso Tomcat, gestisce tutte queste cose.

Oltre a ciò, è necessario tenere presente alcune considerazioni sull'elaborazione multi-thread nel codice. Ad esempio, poiché i servlet sono singleton e molti thread sono generati per questa classe è una cattiva idea avere attributi di istanza in questi componenti.

Answer 3

Ci sono un paio di opzioni. Indipendentemente dalle restrizioni sui contenitori che potrebbero o meno essere presenti, la generazione di singoli thread su richiesta è quasi sempre una cattiva idea. Non è che questo non funzionerebbe in un ambiente Servlet, ma il numero di thread che è possibile creare potrebbe diventare completamente fuori controllo.

La soluzione più semplice è un semplice pool di thread Java SE vecchio tramite un normale servizio di esecuzione. Avviare il pool in un listener Servlet e fornire l'accesso ad esso tramite alcune variabili statiche. Non eccessivamente carino, ma ha fatto il lavoro. A seconda del caso d'uso esatto, questa potrebbe essere la soluzione migliore (se il tuo caso d'uso è piuttosto di basso livello).

Un'altra opzione è aggiungere OpenEJB alla war e quindi sfruttare l'annotazione @Asynchronous.

Un'altra opzione, è rendersi conto che in genere si utilizza Tomcat se i requisiti aziendali sono estremamente semplici o di basso livello. Questo è praticamente l'intero punto di usare qualcosa come un osso nudo come un Tomcat. Non appena avrai bisogno di aggiungere (tonnellate di) librerie, potresti avere superato Tomcat e potrebbe essere meglio utilizzare un server che ha già la funzionalità necessaria (in questo caso l'esecuzione asincrona). Esempi sono TomEE, GlassFish, Resin, JBoss AS, Geronimo, ecc.

Answer 4

Ho usato CommonJ molte volte e funziona molto bene. Può essere inizializzato e distrutto da un ServletContextListener.