Perché unire i bean di sessione Stateless?

Question

I bean stateless in Java non mantengono il loro stato tra due chiamate dal client. Quindi, in poche parole, potremmo considerarli come oggetti con metodi aziendali. Ogni metodo accetta parametri e restituisce risultati. Quando viene invocato il metodo, alcune variabili locali vengono create nello stack di esecuzione. Quando il metodo ritorna, i locali vengono rimossi dallo stack e se alcuni oggetti temporanei sono stati allocati, vengono comunque spazzati via.

Dal mio punto di vista, ciò non differisce dal metodo di chiamata della stessa singola istanza da thread separati. Quindi perché un contenitore non può usare un'istanza di un bean invece di metterne in pool un numero?

Answer 1

Il pooling fa diverse cose.

Uno, avendo un bean per istanza, sei sicuro di essere thread-safe (i servlet, ad esempio, non sono thread-safe).

Due, riducete qualsiasi potenziale tempo di avvio che potrebbe avere un bean. Mentre i bean di sessione sono "apolidi", devono solo essere apolidi nei confronti del cliente. Ad esempio, in EJB, è possibile iniettare diverse risorse del server in un bean di sessione. Tale stato è privato per il bean, ma non c'è motivo per cui non sia possibile impedirlo dall'invocazione all'invocazione. Quindi, unendo i bean si riducono queste ricerche affinché avvengano solo quando viene creato il bean.

Tre, è possibile utilizzare il bean pool come mezzo per limitare il traffico. Se hai solo 10 bean in un pool, otterrai al massimo 10 richieste contemporaneamente, il resto verrà messo in coda.

Answer 2

Il pooling migliora le prestazioni.

Una singola istanza che gestisce tutte le richieste / thread porterebbe a molti conflitti e blocchi.

Dato che non sai quale istanza verrà utilizzata (e più thread potrebbero usare contemporaneamente una singola istanza), i bean devono essere thread-safe.

Il contenitore può gestire le dimensioni del pool in base all'attività effettiva.

Answer 3

La transazionalità del modello Java EE utilizza il contesto del thread per gestire il ciclo di vita della transazione.

Questa semplificazione esiste in modo che non sia necessario implementare alcuna interfaccia specifica per interagire direttamente con l'oggetto UserTransaction; quando la transazione viene recuperata da InitialContext (o iniettata nel bean di sessione), viene associata a una variabile thread-local per il riutilizzo (ad esempio se un metodo nel bean di sessione senza stato chiama un altro bean di sessione senza stato che utilizza anche una transazione iniettata. )

Answer 4

Ciclo di vita dei bean di sessione di Statelesss Non esiste, Passivo e MethodReady (Passivo o Inattivo). Per ottimizzare le prestazioni, invece di attraversare il bean dalla creazione allo stato pronto per il metodo, il contenitore gestisce il bean tra attivo e stati passivi attraverso i callback del contenitore - ejbActivate () ed ejbPassivate () gestendo il pool di bean.

sreenut

Answer 5

I metodi per natura SONO FILATI SICURI (incluso statico). Perché? Semplice, perché ogni variabile all'interno del metodo viene creata nella memoria dello stack, ovvero ogni variabile utilizzata all'interno del metodo viene creata per chiamata (non è condivisa). Tuttavia, i parametri non fanno parte dello stack.

Tuttavia, un metodo non è sicuro se utilizza una variabile non sicura:

a) chiamando un campo statico o una variabile. Tuttavia, succede in ogni singolo caso.

b) chiamando una risorsa che è condivisa. Come EntityManager.

c) passando un parametro che non è sicuro.