Newsgroup: it.comp.java
Titolo: [J2EE] Multithread

Salve ragazzi,
com'è noto, le specifiche J2EE proibiscono all'interno di un application 
server di avviare thread "indipendenti" (ad esempio, lanciare due thread 
all'interno del metodo di una servlet) dal momento che ogni thread deve 
essere sotto il controllo del container.
Ora, in diversi casi mi sono imbattuto in situazioni in cui la possibilità 
di avviare thread in parallelo sarebbe stata parecchio utile. Ad esempio a 
fronte di una richiesta singola da parte del client (web o rich client che 
fosse) mi sono trovato nella necessità di accedere al db per operazioni ben 
diverse (caricare una lista di valori predefiniti, eseguire delle 
decodifiche, eseguire delle query). Il problema può essere aggirato 
sviluppando il client in modo  che esegua n richieste distinte anzichè una 
sola:  tuttavia, mi è sembrato che l'impossibilità di eseguire server-side 
operazioni concorrenti fosse un po' limitante.
Voi che ne pensate ?
Scorpio. 

 Scorpio.
Ciao Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 pensare di agganciare S1 alla Session per evitare guai
Ecco , ripensandoci non e' safe manco questo.
O meglio lo potrebbe essere sarebbe se si conoscessero gli algoritmi di
balancing degli appserver / cluster HW.
Perche' se l'algoritmo mi riporta sempre sullo stesso nodo del cluster sarei
forse safe.
ma se l'algoritmo replica la session su tutto il cluster salto in aria.
Come vedi siamo in un campo minatissimo a infrangere i divieti.
Il caso pero' delle 2 query, che e' rappresentativo di un vasto uso dei 3d
continuo a ritenerlo "thread safe".
N


 ma se l'algoritmo replica la session su tutto il cluster salto in aria.
Mah, come siano realizzati in dettagli gli algoritmi di load balancing non 
lo so, ma cosě, a colpo d'occhio,
penso che sia difficile che esista una "thread migration" tra due nodi del 
cluster, all'interno della stessa richiesta: che vantaggio ne avrei ? Di 
solito si tende ad eseguire un'assegnazione round-robin ai nodi del cluster.
Secondo me, molto IMHO, in J2EE dovrebbe essere implementato o previsto 
almeno un meccanismo di creazione di thread all'interno di EJB o servlet, 
magari, per rispettare anche le problematiche che hai evidenziato in fase di 
migrazione dei processi (o dei thread) tra nodi, con qualche estensione 
specifica dei Thread per quell'ambito.
Scorpio.

 po' limitante.
francamente l'esempio non mi sembra dei più felici: gli accessi al 
database non sono, a mio modesto avviso, fra le attività più sane da 
parallelizzare... 
ma a parte questo, sollevo anche una eccezione generica su questa idea. 
considera che parallelizzare le operazioni non è una ottimizzazione a 
prescindere, trovi beneficio solo su macchine multiprocessore e 
distribuendo il lavoro su un numero di thread determinato in base al 
numero dei processori, altrimenti ottieni l'effetto esatto contrario 
(questo articolo è un po' vecchiotto ma ti garantisco che rende l'idea 
anche sulle jvm recenti: 
http://java.sun.com/developer/technicalArticles/
Programming/JVMPerf/). non è che non si faccia, anzi, però sono 
ottimizzazioni che le fai sullo specifico hardware altrimenti sono 
inutili quando non dannose. 
questo per dire che imho dovresti orientarti sul fare multiple richieste, 
come peraltro "suggeriscono" i model dei principali framework web (jsf in 
primis) e rich client (swing).
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/


Domanda n.1: queste operazioni stanno tutte nella stessa transazione,
magari pure distribuita?
Domanda n.2: (riprendendo il discorso rootkit) sei sicuro che
parallelizzare le query sia veramente un'ottimizzazione, soprattutto
in caso di un server di produzione che macina incessantemente query?
Cmq per implementare i meccanismi di parallelizzazione /
sincronizzazione funziona bene usare (ad esempio) JMS o altri tipi di
code di messaggi, ma anche lì ci sono controindicazioni e
considerazioni da fare.
Spero di essere stato d'aiuto, ciao ciao
--
www.megadix.it

 con qualche estensione specifica dei Thread per quell'ambito.
chiaramente va analizzato caso per caso, ma considera che esistono anche 
gli mbean che, normalmente, è più "igienico" eseguire in modo asincrono.


 primis) e rich client (swing).
Ok, questa è una soluzione fattibile senza troppi mal di testa, ed in 
effetti
ero orientato a seguirla proprio per non "cozzare" contro i divieti di 
J2EE....
Scorpio


Spero di essere stato d'aiuto, ciao ciao
Certo !
    Scorpio.
--
www.megadix.it
 

 Scorpio.
Scoprio se va tutto bene
a settembre ci offri a tutti una pizza e birra lol :-))))
ciao Nicola


 ciao Nicola
Se non fosse per eventuali problemi di distanze geografiche - ed il fatto 
che putroppo vivo in ufficio :-) - personalmente non mi spiacerebbe 
partecipare a qualche "meeting" del newsgroup. Certo, non potrei offire 
pizza e birra a tutti..... *forse* i salatini (LOL) per l'aperitivo :-)
Scorpio

 Scorpio
