È sicuro iniettare un bean in un servlet come variabile di istanza?

Question

Sappiamo tutti che nel livello Web esiste la possibilità che esista una sola istanza di un determinato Servlet che serve più richieste. Ciò può causare problemi di threading nelle variabili di istanza.

La mia domanda è: è sicuro iniettare un bean usando l'annotazione @EJB in un servlet come variabile di istanza?

Il mio istinto iniziale sarebbe no, supponendo che la stessa istanza del bean potesse servire più richieste contemporaneamente. Sembrerebbe che questo sarebbe anche l'istinto di un numero di altri programmatori: Non iniettare in servlet

Comunque ho saltato alla conclusione sbagliata. Chiaramente, ciò che viene iniettato nel servlet è un proxy, sotto il cofano il contenitore effettivamente soddisfa ogni richiesta con un'istanza diversa e mantiene la sicurezza del thread? Come suggerirebbe questo forum: Iniettare su servlet

Sembra che ci siano molte opinioni contrastanti. CHE COSA È CORRETTO ???

Answer 1

Il tuo riferimento " Non iniettare in servlet " non menziona nulla sull'ejbs o sull'annotazione @ejb. Parla di oggetti thread non sicuri come PersistenceContext.

Per le specifiche EJB è possibile accedere a ejbs da una varietà di client remoti, inclusi servlet (specifica EJB 3.0 (JSR-220) - Sezione 3.1). L'iniezione di ejb mediante l'annotazione @EJB è un metodo per ottenere l'interfaccia EJB tramite l'iniezione delle dipendenze (sezione 3.4.1) che è alternativa alla ricerca di oggetti ejb nello spazio dei nomi JNDI. Quindi non c'è nulla di speciale nell'annotazione @EJB rispetto agli EJB ottenuti.

Quindi, in base alle specifiche EJB 3.0, è una pratica standard ottenere ejbs dai servlet usando l'annotazione @EJB.

Answer 2

È sicuro iniettare un bean in un servlet come variabile di istanza servlet, purché il bean sia stateless. NON DEVI MAI iniettare un fagiolo con stato in un servlet.

È necessario implementare il bean EJB senza stato in quanto non contiene alcuna variabile di istanza che a sua volta ha un valore con stato (come il contesto di persistenza). Se è necessario utilizzare il contesto di persistenza, è necessario ottenerne un'istanza nei metodi dell'EJB. Puoi farlo avendo un PersistenceContextFactory come variabile di istanza EJB e quindi ottieni un'istanza del gestore entità dalla Factory nel metodo dell'EJB.

PersistenceContextFactory è thread-safe, quindi può essere iniettato in una variabile di istanza.

Finché si rispettano le regole sopra menzionate, dovrebbe essere sicuro per i thread iniettare un fagiolo apolide in un servlet

Answer 3

È un miscuglio.

I bean di sessione senza stato possono essere iniettati e sono sicuri. Questo perché anche se viene utilizzata una singola istanza di uno stub, l'accesso ai metodi verrà serializzato dal contenitore.

Penso che ciò che dice inferreddesign sia non vero . Non importa se il bean di sessione senza stato utilizza un contesto di persistenza. Solo un chiamante accederà mai a una singola istanza di bean contemporaneamente, quindi anche se il contesto di persistenza non è thread-safe, l'EJB protegge da un accesso multiplo. Pensalo come se ad ogni metodo del bean di sessione fosse applicata la parola chiave sincronizzata.

Il problema principale con l'iniezione di un bean in un servlet penso sia la prestazione. La singola istanza di stub diventerà la principale area di contesa quando più richieste vengono messe in coda durante l'attesa per l'esecuzione di un metodo bean di sessione.

Answer 4

Penso che la risposta semplice sia che non sei sicuro che sia sicuro.

La ragione di ciò è che non c'è nulla di esplicito nella specifica EJB che dice che le interfacce home EJB devono essere thread-safe. La specifica delinea solo il comportamento della parte lato server. Quello che probabilmente scoprirai è che gli scheletri client sono effettivamente thread-safe, ma dovresti guardare come sono implementati dalla libreria che stai usando. La parte delle annotazioni si espanderà semplicemente in un localizzatore di servizi in modo da non comprarti nulla.