[EJB] Session Bean Stateless o Stateful? Quando utilizzarli

[Flaka]

Salve,
come da oggetto vorrei capire come decidere se utilizzare un bean Stateless o uno Stateful...
In linea teorica ho capito entrambi i cicli di vita.. ma non riesco a capire con esempi pratici quando utilizzare uno e quando l'altro...

Ad esempio... se ho un elenco di voci da stampare su una pagina html, e queste voci sono indipendenti dal client che le richiede. Questo elenco è memorizzato nel database quindi deve fare una semplice query.

Cosa mi conviene utilizzare? Stateless o Stateful?

Vedo pro e contro in entrambi i tipi...

Stateless
Pro: l'output è indipendente dal client che ne ha effettuato la richiesta
Contro: effettua per ogni richiesta della pagina una query

Stateful
Pro: potrei memorizzare l'output in una variabile d'istanza senza dover effettuare ogni volta la query(anche se dopo un tot di giorni deve aggiornarsi con il database)
Contro: non mi serve che esso abbia un'associazione 1:1 con il client (sprecandomi così abbastanza risorse)


Ho scritto un pò i miei ragionamenti... come devo ragionare in merito?

[c0der]

queste voci sono indipendenti dal client che le richiede

Allora un entity bean, vedi per esempio questo specchietto:
http://publib.boulder.ibm.com/infoce...%2Fdfhpji2.htm

[Flaka]

si ok è un entity bean ma devo pur fare la query su di esso.. ad esempio ho una classifica e la devo stampare su una pagina html... Classifica è una tabella del mio database ed anche un Entity Bean del mio progetto e devo eseguire una query su di esso del tipo SELECT * FROM Classifica.

In un ejb session bean devo eseguire tale query giusto? Il mio dubbio è quello di capire quando utilizzare STATELESS e quando STATEFUL... in un contesto del genere cosa è consigliabile usare?

Ciao

[c0der]

Hai ragione, sono rimasto un po' indietro con queste cose.
Guardando qui:
http://docs.oracle.com/javaee/6/tutorial/doc/gipjg.html
mi sembra che siano i "Singleton Session Beans" quelli che cerchi.
Ciao.

[Flaka]

Sono rimasto anche io un pò dietro allora... ero rimasto a Stateful e Stateless anche se su netbeans avevo letto questo terzo tipo... e conoscendo il pattern singleton ci avevo anche pensato ma ho postato non tanto per capire un singolo esempio ma in generale... e da quanto ho capito lo stateful si deve utilizzare solo nel caso in cui si ha la necessità di mantenere la comunicazione con lo stesso client. Se sbaglio qualcuno mi correggesse per favore...

un'altra domanda..... è abbastanza analoga a questa (forse mi conviene aprire un altro thread) quando devo stampare su una pagina html l'output fornito da un session bean, ad esempio in questo contesto della classifica, utilizzando un Managed Bean cosa conviene utilizzare tra i vari scope RequestedScope SessionScoped ViewScoped ecc

E in sintesi in generale in che casi si utilizzano i vari scope?

[francesco.muia]

Allora cerchiamo di fare un pò di chiarezza....
Quello che ti manca di capire è il concetto di "Stato" sia per quanto riguarda gli EJB che per i ManagedBean.
Un ejb Stateless è un ejb privo di stato o meglio che non mantiene lo stato, viceversa un Statefull ejb è un ejb che invece mantiene lo stato.
Il concetto di stato di un ejb è un concetto un pochino ostico da capire e sopratutto da spiegare in un semplice post; per capire meglio faccio un esempio:
Supponiamo che nel tuo Ejb avrai due metodi (metodoA e metodoB) nel metodoA a seguito di una elaborazione setterai una proprità di instanza del bean (private bolean property) a true e nel secondo metodo andrai a leggere questa proprietà e in base al valore effettuerai due operazioni diverse.
Quindi una corretta invocazione del metodoB prevede che il client richiami prima il metodoA; quindi lato client avrai una prima invocazione ejb.metodoA(); e subito dopo ejb.metodoB().
Cosa cambia se l'ejb è stateless o statefull ?
Se stateless non vi è la certezza che l'istanza dell'ejb su cui richiami il metodoA sia la stessa su cui poi andrai a richiamare il metodoB cioè la chiamata ai due metodi potrebbe essere dirotatta su due ejb diversi questo perchè l'application server suppone che (Stateless) la cosa possa essere fatta; viceversa dichiarandolo come statefull questo non avverà mai perchè l'application server invocherà i due metodi su gli stessi ejb.

[francesco.muia]

Integro anche la parte sui ManagedBean (JSF),da adesso BB. Gli scope dei BB servono a gestire il ciclo di vita di quest'ultimi in base alle varie richieste (Request) effettuate.
Gli scope dei jsf managedBean sono :
[list=1][*]@RequestScope
Il BB viene ricreato ad ogni richiesta ricevuta. Ergo se dichiare un variabile di instanza all'interno di request BB essa verra ricreata e reinizializzata ad ogni richiesta (Action) che il bb gestirà[*]@SessionScope
Il BB viene creato solamente una volta per HttpSession dell'utente e viene posto nella mappa di sessione, questo vuol dire che il BB deve essere Serializzabile per essere appunto salvato all'interno della mappa. Questo tipo di BB sono spesso usati per mantenere dati che devo condividere il ciclo di vita della Sessione Web per esempio un BB che ha come proprietà l'utente attualmente loggato potrebbe essere un Session Bean[*]@ViewScope
Questo scope è stato introdotto con la specifica di JSF 2 (anche se molte implementazioni di jsf 1, vedi richfaces, già ne facevano uso). Il BB dichiarato come ViewScope viene creato alla prima action che riceve da una JSF View ("Pagina") e continua a mantenere il proprio stato finchè non riceve un action da un'altra pagina oppure se viene effettuata una redirect verso un'altra pagina.
Diciamo che è uno stato intermedio tra un SessionBean e un RequestBean.
Anche questo per mantenere il proprio stato ha bisogno di essere serializzato.[/list=1]
Su quando usare uno stato rispetto ad un'altro non vi è una regola generale ma dipende appunto dal comportamento che il BB deve avere.
Se però posso azzardare un consiglio è quello di limitare (non abbolire) l'uso dei Session Bean in quanto essendo posto nella mappa di sessione vanno ad occupare memoria per tutto il tempo che la sessione sarà attiva e dato che la memoria di un application server è destinata a tutti i client e soprattuto a tutte le web app che sono publicate su di esso, occupare tanta memoria non è una buona cosa, per farti capire ti porto un esempio:
Se la tua app usa 10 mega di sessione e supponiamo che avrai una media di client connessi uguale a 10, la media di memoria occupata sarà di 100 MB il che non è un problema se guardi solamente al tuo applicativo ma se sullo stesso application server ci sono deployate 10 applicazioni che fanno il tuo stesso uso di memoria arriverai ad occupare 1 giga di memoria....

[Flaka]

ciao francesco ti ringrazio molto per i chiarimenti... per i session bean mi è già più chiaro.. per i BB con uno scope REQUESTED nel caso in cui ho una pagina in cui esso viene istanziato se la pagina viene aggiornata corrisponde ad una nuova request quindi ad una nuova istanza del bean ma nel caso in cui la pagina utilizzasse ajax per ricaricare parte del suo contenuto corrisponderebbe ad una nuova request --> quindi alla reinizializzazione del bean...oppure no?

per la viewscoped non mi è tanto chiara... perchè diciamo che ho 2 pagine SEARCH.XHTML e INFO.XHTML ed un BB(mBean1).
Io in SEARCH seleziono una voce tra quelle disponibili (mbean1 si preoccuperà di elencargli le disponibili) una volta che il client ha selezionato la voce(verrà settata in una proprietà di mbean1 la voce selezionata) e viene fatto un redirect verso INFO.XHTML... una volta reindirizzato su INFO.XHTML mi mostrerà tutte le info della voce selezionata.
Ma mbean1 a quanto ho capito non dovrebbe perdere il suo stato una volta fatto il redirect su info.xhtml?

[francesco.muia]

Originariamente inviato da Flaka
ma nel caso in cui la pagina utilizzasse ajax per ricaricare parte del suo contenuto corrisponderebbe ad una nuova request --> quindi alla reinizializzazione del bean...oppure no?

Esatto

per la viewscoped non mi è tanto chiara... perchè diciamo che ho 2 pagine SEARCH.XHTML e INFO.XHTML ed un BB(mBean1).
Io in SEARCH seleziono una voce tra quelle disponibili (mbean1 si preoccuperà di elencargli le disponibili) una volta che il client ha selezionato la voce(verrà settata in una proprietà di mbean1 la voce selezionata) e viene fatto un redirect verso INFO.XHTML... una volta reindirizzato su INFO.XHTML mi mostrerà tutte le info della voce selezionata.
Ma mbean1 a quanto ho capito non dovrebbe perdere il suo stato una volta fatto il redirect su info.xhtml?

Sicuro che è cosi, ma sei sicuro che stai facendo una redirect è non una semplice navigazione ?

[Flaka]

Si scusami il bean era @SessionScoped pensavo @ViewScoped.
Ma comunque nemmeno nel caso in cui fosse una semplice navigazione col view mantengo lo stato..

E scusami se continuo ancora con i miei dubbi ma sto riuscendo a capire meglio tali concetti togliendomi i miei dubbi....

Un caso pratico in cui si può usare il @ViewScoped quale può essere?
Un caso in cui con VIEW riesco a mantenere lo stato mentre con la REQUEST lo perdo... non riesco a vedere dove finisce lo scope di uno e inizia l'altro