2011-11-19 18 views
7

Se il bean di sessione stateful sta per passivare, il suo stato viene scritto su harddisk e quindi l'istanza bean verrà liberata per servire altre richieste (almeno questo è il mio punto di vista). Quando lo stesso client è di nuovo attivo, l'istanza bean leggerà lo stato dal disco rigido per ripristinare lo stato. Ma in che modo l'istanza di bean sa che per quale client deve leggere il file per mantenere lo stato?In che modo un bean di sessione con stato ripristina lo stato quando il client ritorna?

Sono molto nuovo a J2EE, quindi scusatemi se sto chiedendo un dubbio molto ingenuo. Se ho bisogno di conoscere qualsiasi altro argomento per capire questo, per favore indicami la giusta direzione.

risposta

13

È meglio visualizzare uno Stateful Session Bean (SfSB) molto simile a un'istanza di una normale classe Java. Si cerca (o si inietta) un'istanza di uno SfSB e il contenitore ne creerà uno per te e restituirà l'istanza. Quindi lavorerai con quell'istanza come faresti con qualsiasi altra istanza Java.

Ciò significa che è possibile memorizzare l'istanza in una sessione, serializzare disco, ecc

Il dettaglio è che l'istanza si sta lavorando è in realtà un proxy al reale, sottostante esempio SFSB. Non è lo stesso SfSB in sé.

Quando si effettua una chiamata sul proprio proxy locale sul bean, è il lavoro container a manifestare il bean in memoria per conto dell'utente. La passivazione e l'attivazione del bean vengono eseguite dietro le quinte per te (anche se puoi attingere al processo attraverso il ciclo di vita dei bean).

Qualsiasi informazione che il contenitore ha bisogno di trovare lo SfSB passivato è memorizzata nel proxy con cui si sta lavorando, ma questo è opaco. Non devi preoccuparti di questo.

Quindi, in un tipico scenario basato sul Web, il ciclo di vita potrebbe essere quello di ottenere l'istanza del bean, memorizzarla in una sessione Web e quindi semplicemente usarla come normale. Se il contenitore decide che ha bisogno di passivare il tuo fagiolo per fare spazio o altro, lo passiverà automaticamente per te. Quando l'utente torna, la tua app estrae l'istanza dalla sessione Web e fa le sue chiamate. A quel tempo, se il bean è passivato, il contenitore attiverà automaticamente il bean per te. L'intero meccanismo dipende dal contenitore, ma è trasparente per te. La cosa importante da ricordare è che devi attaccarti a SfSB che ti viene dal contenitore, come faresti con qualsiasi oggetto java.

L'avvertenza finale è che se si consente a un SFSB di essere passivato troppo a lungo, il contenitore lo eliminerà automaticamente.

+0

Grazie Will per la spiegazione. Ma è possibile che un utente ritorni dopo che lo SfSB è stato cancellato? E se è possibile, cosa accadrà in quello scenario? – Bhushan

+2

Sì, è assolutamente possibile. Se succede, otterrai un'eccezione quando proverai ad accedere a SfSB (l'esatta eccezione, non saprei dire). Il timeout di un SfSB è configurabile (tramite un'annotazione in EJB 3.1 o tramite un meccanismo specifico del contenitore in EJB 3), quindi l'obiettivo sarebbe quello di legare la durata del timeout alla durata prevista dello stato. Detto questo, non li darei in misura illimitata. Inoltre, è molto probabile che SfSB non sopravviva alla ridistribuzione dell'applicazione. Riavvio del server, sì, ma non ridistribuzione. –

Problemi correlati